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.
