https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
--- Comment #25 from Alexander Monakov <amonakov at gcc dot gnu.org> --- (In reply to Richard Biener from comment #24) > As of the patch it looks good, I wonder if we want to check for OPTIMIZE_BOTH > though since at least when no extra negations are required the contraction > should also be a win when optimizing for size? Makes sense, I'll change that (current target hooks always return true for fma). > Also I wondered about the PROP_gimple_any check - do we get into the > gimplification langhook after lowering? I see we are not resetting the > langhook after lowering (only in free-lang-data, but that only runs with > LTO). Yes, that surprised me. I caught it when analyzing ICE on slp-50.c testcase. > We probably at least should gate the langhook invocation in the gimplifier > with what you added in the patch or specify whether the gimplifier is > invoked from the middle-end via the gimplifier context. Perhaps. I'll add a comment that we want to handle -ffp-contract=on strictly during initial gimplification, to hash this out further on gcc-patches, if necessary. > If we go for c-family only the genericize entry could be another place to > handle this. That seems less convenient to me. Is IFN_FMA representable as a tree? > Did you run into any of NON_LVALUE / C_MAYBE_CONST wrappings of the > multiplication btw? No, I'm not familiar with those, so I didn't try to construct corresponding testcases.
