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: unfused fma question


On Mon, Feb 23, 2015 at 7:59 PM, Marc Glisse <marc.glisse@inria.fr> wrote:
> On Mon, 23 Feb 2015, Jeff Law wrote:
>
>> On 02/23/15 11:38, Joseph Myers wrote:
>>>
>>>
>>> (I wonder if convert_mult_to_fma is something that should move to
>>> match-and-simplify infrastructure.)
>>
>> Yea, it probably should.
>
>
> Currently, it happens in a pass that is quite late. If it moves to
> match-and-simplify, I am afraid it might inhibit some other optimizations
> (we can turn plus+mult to fma but not the reverse), unless we use some way
> to inhibit some patterns until a certain pass (possibly a simple "if", if
> that's not too costly). Such "time-restricted" patterns might be useful for
> other purposes: don't introduce complicated vector/complex operations after
> the corresponding lowering passes, do narrowing until a certain point but
> then prefer fast integer sizes, etc (I haven't thought about those
> particular examples, they are only an illustration).

These concerns are correct.  Btw, as an answer to Steve - within
-funsafe-math-optimizations FMA_EXPR basically can be either
fused or not fused (but yes, bad as to Josephs concern).
So you could guard the pattern by flag_unsafe_math_optimizations.

Richard.

> --
> Marc Glisse


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