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

[amacleod at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154

--- Comment #37 from Andrew Macleod <amacleod at redhat dot com> ---
Created attachment 54780
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54780&action=edit
in progress patch

Well call me a liar. 

It took me a while to understand why, but if we leave it to single dependencies
only, the impact is relatively linear.  I wrote a bunch of code, then deleted
most of it as I found the engine was bypassing my code and doing it on its own.

The attached patch is the core.  It actually works to a depth of 5
recomputations. my sample of:
  int a = left * 2;
  int b = a - 4;
  int c = b % 7;
  func (a,b ,c);
  int d = c * 4;
  if (left == 20)
    {
      func (b,c,d);

produces 
  <bb 5> :
  func (36, 1, 4);

IT also changes your program somewhat.

Try applying it and see if it does what you want. It bootstraps, regression are
running.. but based on the minimal code impact, I wouldn't expect incorrect
failures.

Performance impact on building GCC is barely half a percent in VRP, and 0.05%
overall compile time.  pretty minimal.

Im still working with it to tweak it, I just wanted you to be able to see if it
helps.  I presume we dont want to add a new --param this late in the game.  
But it seems we can set a reasonable number and not run into much trouble.