[Bug tree-optimization/93332] target-dependent inaccurate range info for some expressions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That is not really a bug nor anything weird, depending on BRANCH_COST etc.,
GIMPLE is different already from the start,
  z_22 = vals[i.4_20];
  _23 = z_22 == 0;
  _24 = z_22 > 2;
  _25 = _23 | _24;
  if (_25 != 0)
on x86, while
  z_19 = vals[i.4_17];
  if (z_19 == 0)
    goto <bb 5>; [50.00%]
  else
    goto <bb 3>; [50.00%]

  <bb 3> [local count: 536870913]:
  if (z_19 > 2)
    goto <bb 4>; [50.00%]
  else
    goto <bb 5>; [50.00%]

  <bb 4> [local count: 268435457]:
And vrp works as designed, in both x86_64 and powerpc64 vrp1
-fdump-tree-vrp-alias-details dump you can see:
  # RANGE [2, 4] NONZERO 6
  iftmp.0_3 = iftmp.6_26 * 2;
  # PT = { D.2388 } (escaped, escaped heap)
  # USE = nonlocal { D.2388 D.2389 } (escaped, escaped heap)
  # CLB = nonlocal { D.2388 D.2389 } (escaped, escaped heap)
  _5 = operator new [] (iftmp.0_3);
so VRP knows and recorded that the first operator new allocates 2-4 bytes.
The thing that happens is that due to the differen CFG PRE decides to optimize
and the value range info we have stored in the IL isn't something that is
recomputed all the time any time we perform some optimization, so as soon as
some optimization pass creates something new or invalidates the range info, it
is thrown away.  During vrp2 it will be computed again.

So, guess you are looking for the stuff Andrew/Aldy work on, which will allow
the range info to be computed in other passes too.