Re: grokfield miscompiled with -O9

[Alexandre Oliva <oliva at lsd dot ic dot unicamp dot br>]

On Jan 11, 2000, Jeffrey A Law <law@cygnus.com> wrote:

>   In message <orln5y7c0v.fsf@garnize.lsd.ic.unicamp.br>you write:
>> 
>> BTW, the code fragment in i386.c:ix86_expand_setcc got me wondering
>> why it would be of any help to generate a scratch QI register to
>> store CC, and whether it had not been coded the way it was because
>> of the bug fixed (?) in the patch above.

> I don't see how this code can be correct.

> The whole point of that case is to deal with overlaps between the source
> and the dest.

And it does, even without using a scratch register.

> In that case you need some kind of scratch register so that you do
> not stomp on your source operand before you're done reading it.
> Right?

I don't think so.  Only the first insn it generates reads the source,
and stores the result of the computation in a SUBREG of dest.  The
second insn just zero-extends the SUBREG, so its previous value no
longer matters.  Moreover, these insns don't even refer to the
original operands of the compare insn.  I.e., the choice is whether to
emit:

(set (reg:CCNO ...) (compare:CCNO ...))
(set (subreg:QI (reg:SI #dest) 0) (... reg:CCNO ...))
(set (reg:SI #dest) (zero-extend:SI (subreg:QI (reg:SI #dest) 0)))

or

(set (reg:CCNO ...) (compare:CCNO ...))
(set (subreg:QI (reg:SI #scratch) 0 (... reg:CCNO ...))
(set (reg:SI #dest) (zero-extend:SI (subreg:QI (reg:SI #scratch))))

I doubt the CSE pass would benefit from the scratch pseudo, given that
it would still be available as a subreg of dest anyway.  But then, I
don't claim to be an expert on the CSE pass of GCC, so I may well be
wrong.


I'd love to know why the initialization of tmp for `type == 1' had
been coded the way it was (i.e., depending on cse_expect_reload), but
neither CVS logs nor the ChangeLog help.  In fact, not even
ChangeLog.P2 in the ia32 branch mentions this change.  The rationale
is probably hidden in some file that was never part of the GCC CVS
tree, and I believe it is no longer an issue.

> I'd be more interested in fixing the code which pessimizes the code
> by setting the type to one instead of zero.

This is an unrelated issue, that I have addressed in another message.

-- 
Alexandre Oliva http://www.ic.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{lsd.ic.unicamp.br,guarana.{org,com}} aoliva@{acm,computer}.org
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them