This is the mail archive of the 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: [RFC] Fix PR28684

> For virtually, all users -ffast-math is the the correct optimization
> flag use to get efficient floating point code.  (It's a pity this
> isn't the -O default as it is with most commericial compilers). However,
> for PR28684 it turns out there are a subset of numerical programmers
> who are interested in hardware Mflop count.  In this usage, operations
> may be significantly reordered, but it still isn't legitimate to turn
> x+x+x into x*3 (the first requires 2 flops, the second requires only
> one).

I think that those numerical programmers could benefit from a wider
optimizations in the former definition (like variable-expansion)
> Concepts like -freciprocal-math whilst interesting, are little
> more than an arbitrary reclassification of existing unsafe math
> optimizations.  They also blur the boundaries of which optimizations
> do we consider associative and which do we consider reciprocal,
> and some transformations may be difficult to categorize etc...
> Is C1/(X*C2) into (C1/C2)/X reasonable?

As I understood reciprocal operations are associative so in terms of
arithmetic law C1/(X*C2) -> (C1/C2)/X should go under the assosiative
flag. The special thing about this transformation is that it involves
which might interest the user so this is why it should be under the
reciprocal flag.


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