Re: [patch, ia64] Patch for PR target/44583 to fix signed zeros

[Steve Ellcey <sje at cup dot hp dot com>]

On Fri, 2010-07-30 at 11:27 -0700, Richard Henderson wrote:
> On 07/29/2010 01:45 PM, Steve Ellcey wrote:
> > +(define_constraint "Z"
> > +  "1.0 or (0.0 and !flag_signed_zeros)"
> > +  (and (match_code "const_double")
> > +       (ior (match_test "op == CONST1_RTX (mode)")
> > +	    (and (match_test "op == CONST0_RTX (mode)")
> > +		 (match_test "!flag_signed_zeros")))))
> 
> That can't be right.  The pointer equality there, as in "G",
> should mean that we know we really have a positive zero,
> which *can* use FP0.
> 
> It would seem you're pessimizing every instance of "x = y + 0".
> 
> Which operation is it, specifically, that's failing?

It is an fadd with f0 that is failing.  If I compile the example in
comment #8 from PR 44583 it passes with my change but not with
the current ToT.  

The ToT code generated for foo (without the patch) is:

foo:
        fadd.s f8 = f8, f0
        fmerge.s f8 = f8, f1
        br.ret.sptk.many b0
        .endp foo#

The new code (using my patch) is:

foo:
        mov f6 = f0
        fadd.s f8 = f8, f6
        fmerge.s f8 = f8, f1
        br.ret.sptk.many b0
        .endp foo#

The old code causes an abort, the new code works.  My understanding of
the problem is that if the hardware sees that the second argument to
fadd (or fsub) is f0 it doesn't do the add operation and passes the
first argument straight through.  Thus if f8 happens to have -0 in it
you get -0 out.  But if the second argument to fadd is a normal register
it does do the add and if the first argument is -0 we add (-0) to (+0)
and get +0 which is the correct answer.

Steve Ellcey
sje@cup.hp.com