[Bug tree-optimization/109154] [13/14 regression] jump threading de-optimizes nested floating point comparisons

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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 ...