This is the mail archive of the
mailing list for the GCC project.
Re: unfused fma question
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: GCC Development <gcc at gcc dot gnu dot org>
- Cc: Jeff Law <law at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>, Steve Ellcey <sellcey at imgtec dot com>
- Date: Tue, 24 Feb 2015 13:14:09 +0100
- Subject: Re: unfused fma question
- Authentication-results: sourceware.org; auth=none
- References: <02d0fee7-2c86-4291-8405-ae250d3210d9 at BAMAIL02 dot ba dot imgtec dot org> <alpine dot DEB dot 2 dot 10 dot 1502231833070 dot 7064 at digraph dot polyomino dot org dot uk> <54EB73FD dot 1000003 at redhat dot com> <alpine dot DEB dot 2 dot 11 dot 1502231946100 dot 1758 at laptop-mg dot saclay dot inria dot fr>
On Mon, Feb 23, 2015 at 7:59 PM, Marc Glisse <firstname.lastname@example.org> 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.
> Marc Glisse