https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103253
--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 16 Nov 2021, tnfchris at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103253 > > --- Comment #7 from Tamar Christina <tnfchris at gcc dot gnu.org> --- > > .COND_MUL might raise an exception and DCE removes unused LHS of calls. > > Looks like FMA analysis doesn't like internal fns w/o a LHS? > > That makes sense, it looks like it needs the LHS to find the uses to see if > it's an ADD. So likely `convert_mult_to_fma` should return false if there's > no > LHS as there are no uses then and it can't be an FMA. Yes. As said, it's odd that .COND_MUL prevails, so maybe sth is wrong with its attribute spec. Ah, I think it's the "old" issue of internal-fn.def not being sensitive to -fno-trapping-math. Generally ECF_NOTHROW would be wrong here but with -fno-trapping-math it would be OK. We might want to eventually special-case some of the internal fns in internal_fn_flags? Or have a special ECF_FP_TRAP which we'd rewrite in internal_fn_flags based on flag_trapping_math (but we'd need a caller context to be able to lookup the correct flag_trapping_math here). Alternatively whoever adds those patterns should mark the GIMPLE call as gimple_call_nothrow (that might be genmatch generated code in this case).
