https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
--- Comment #27 from rguenther at suse dot de <rguenther at suse dot de> --- > Am 18.05.2023 um 10:31 schrieb amonakov at gcc dot gnu.org > <gcc-bugzi...@gcc.gnu.org>: > > 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? Yes, that’s possible. Let’s see if others have an opinion on the ml. >> 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. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
