On Mon, Feb 23, 2015 at 7:59 PM, Marc Glisse <marc.gli...@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
