This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Expansion of narrowing math built-ins into power instructions


Richard Sandiford <richard.sandiford@arm.com> writes:
>> And yes, it is icky.  But it is sound, as far as I can see.
>
> I really disagree that it's sound, but no point me saying why again :-)
>
> (It could certainly be made to work with sufficient hacks of course,
> like pretty much anything could, but I don't think that's the same thing.)

For an example, we have:

      /* Maybe simplify x + 0 to x.  The two expressions are equivalent
	 when x is NaN, infinite, or finite and nonzero.  They aren't
	 when x is -0 and the rounding mode is not towards -infinity,
	 since (-0) + 0 is then 0.  */
      if (!HONOR_SIGNED_ZEROS (mode) && trueop1 == CONST0_RTX (mode))
	return op0;

I think it's plausible that people will care about accurate rounding
but not signed zeroes.  In that mode we could have:

    (set (reg:DF r3) (plus:DF (reg:DF r1) (reg:DF r2)))
    (set (reg:DF r4) (const_double:DF 0.0))
    (set (reg:SF r5) (float_narrow:SF (plus:DF (reg:DF r3) (reg:DF r4))))

Then combine through normal structural simplification could (with the
rule above) fold all this down to:

    (set (reg:SF r5) (float_narrow:SF (plus:DF (reg:DF r1) (reg:DF r2))))

where the truncation is now fused with r1+r2 instead of r3+r4.  We would
have to have to add specific checks to avoid this happening, it wouldn't
fall out naturally from structural PoV.

Thanks,
Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]