https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #60 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Tamar Christina from comment #59) > after ifcvt we end up with: > > _162 = chrg_init_70 * iftmp.8_76; > _164 = ABS_EXPR <_162>; > _167 = -_164; > _ifc__166 = distbb_74 < iftmp.0_97 ? _167 : 0.0; > prephitmp_169 = distbb_74 >= 0.0 ? _ifc__166 : _168; > > instead of > > _160 = chrg_init_75 * iftmp.8_80; > prephitmp_161 = distbb_79 < 0.0 ? chrg_init_75 : _160; > _164 = ABS_EXPR <prephitmp_161>; > _166 = -_164; > prephitmp_167 = distbb_79 < iftmp.0_96 ? _166 : 0.0; > > previously we'd make COND_MUL and COND_NEG and so don't need a VCOND in the > end, > now we select after the multiplication, so we only have a COND_NEG followed > by a VCOND. > > This is obviously worse, but I have no idea how to recover it. Any ideas? None. This is with -O3, right? Can you try selectively disabling parts of PRE with -fno-tree-partial-pre -fno-code-hoisting? But I suspect it's the improvement for general PRE that we hit here. One idea that was always floating around was to move PRE after loop opts like we did with predcom. But the no PRE before loop will likely hurt as well so we might instead want to limit PRE when it involves generating constants in PHIs and schedule another PRE after loop opts (at some cost then). It's something to experiment with ...
