https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
--- Comment #24 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Andrew Pinski from comment #23) > (In reply to Alexander Monakov from comment #22) > > Created attachment 55105 [details] > > patch 1/3 > > > > (In reply to Richard Biener from comment #21) > > > > > > Sounds reasonable. Though I wouldn't use GENERIC folding but instead > > > some folding-like code in c-family/ that for example would get invoked > > > by genericization or via the gimplification hook? If we'd add GENERIC > > > folding in fold-const.cc or match.pd the chance is that it will pick up > > > FMAs "late". > > > > Agreed, thank you. I'm working on it. The attached patch implements this via > > c_gimplify_expr and passes bootstrap+regtest under 'configure > > --with-cpu=znver2' (i.e. with fma available by default). > > Hmm, seems like this should not be in the C family but the generic part of > gimplifier. Because IIRC Fortran has similar rules but IIRC fortran > front-end emits PAREN_EXPR a lot more which improves the situtation there ... The actual worker can be put into generic code but frontends need to set the rules here I think as they might differ slightly. 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? 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). 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. If we go for c-family only the genericize entry could be another place to handle this. Did you run into any of NON_LVALUE / C_MAYBE_CONST wrappings of the multiplication btw?
