Bad optimization in PCC?

[Mikael Pettersson]

[]
While hacking a piece of code the other day, I came across what
looks like a case of bad optimization in PCC-derivated compilers.

Relevant C code
---------------
(np, ep and envp are register char *, val is a parameter char *)

(1) while(*np && (*np++ == *ep++))
        /* empty */ ;
(2) if(!*np)
        *envp = val;

Notice that the value of the test at line (2) is known if the '*np'
part of line (1) evaluates to 0.

Actual code generated (compiling flags: -O -S):

Sun CC, SunOS3.2                  GNU CC, ver 1.18 for Sun3
-----------------------------------------------------------
L18:    tstb    a3@               L5:     moveb a1@,d0
     (+)jeq     L19   <-----THIS-----> (+)jeq L6
        cmpmb   a4 at +,a3 at +                 addql #1,a1
        jeq     L18                       cmpb a0 at +,d0
L19:    tstb    a3@                       jeq L5
     (*)jne     L20               L6:     tstb a1@
        movl    a6@(12),a5@            (*)jne L7
L20:                                      movel d1,a2@
                                  L7:

(Goulds UTX/32 cc produced very similar code)

It seems to me that a *good* peep-hole optimizer should be able to
recognize that if the jump at line (+) is taken then the jump at line
(*) will not be taken. So why didn't they generate something like:

L18:    tstb   a3@
     (+)jeq    L19
        cmpmb  a4 at +,a3 at +
        jeq    L18
        tstb   a3@
        jne    L20
L19:    movl   a6@(12),a5@
L20:

which would save the unnecessary test+jump if the jump at (+) is taken?

Any PCC (or GCC) guru out there who have an answer?

Yours
-- 
Mikael Pettersson           ! Internet:mpe at ida.liu.se
Dept of Comp & Info Science ! UUCP:    mpe at liuida.uucp  -or-
University of Linkoping     !          {mcvax,munnari,uunet}!enea!liuida!mpe
Sweden                      ! ARPA:    mpe%ida.liu.se at uunet.uu.net