This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: GCC beaten by ICC in stupid trig test!
On Mar 24, 2004, at 1:51 PM, Joe Buck wrote:
> > And no, I'm not being pedantic; in many scientific apps, the programmer
> > is aware of the expected range of values the variables will have, and
> > will deliberately arrange the operations so that variables of similar
> > magnitudes are combined.
On Wed, Mar 24, 2004 at 01:56:16PM -0500, Bradley Lucier wrote:
> I'm aware of the usual examples. Do you think that we need yet another
> fast-math flag to allow the compiler to reassociate values in
> floating-point arithmetic? -freally-unsafe-math-optimizations perhaps?
> Or maybe such a programmer as you describe will just turn off
> -funsafe-math-optimizations.
No. Why would we need such a thing? If the user does not care about
order of evaluation, the user can write a+b+c . As someone said, right
now we can't tell the difference between a+b+c; if we turn it into GIMPLE
and make t1 = a+b; 52 = t1+c; we can't tell if the user initially wrote
(a+b)+c or a+b+c. I suspect that the main reason people want to go in
this direction is to speed up the second case, where the user has not
specified an order. So, rather than breaking the first case, we need to be
able to distinguish the two cases. I don't know how this should be done;
maybe flag the temporary to say that t1 is required to be computed as is
in the explicit paretheses case, and not required in the other case.