https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102546
Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2021-10-01
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
--- Comment #5 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #4)
> (In reply to Aldy Hernandez from comment #2)
> > By VRP1 we seem to be calculating the following:
> >
> > (f_8 << f_8) && (f_8 == 0)
> >
> > This would fold to false, which would elide the foo():
> >
> > <bb 7> [local count: 59055800]:
> > b = 0;
> > _3 = f_8 << f_8;
> > _4 = (char) _3;
> > _5 = (int) _4;
> > if (_4 > 0)
> > goto <bb 8>; [64.06%]
> > else
> > goto <bb 10>; [35.94%]
> >
> > <bb 8> [local count: 34842922]:
> > if (f_8 == 0)
> > goto <bb 9>; [71.10%]
> > else
> > goto <bb 10>; [28.90%]
> >
> > <bb 9> [local count: 12809203]:
> > foo ();
>
> I think it's similar to in the other PR, with old EVRP when visiting BB 8
> we pushed [1, +INF] as the global range for _4, then supposedly ranger
> manages to evaluate f_8 == 0 with its backward infering somehow.
>
> We no longer do this "path sensitive" adjustment of (global) ranges since
> you removed the EVRP DOM walk algorithm.
The hybrid threader does path sensitive ranges and relationals. What's missing
is the range-op entry for the following relation:
~[0,0] = x << x
In this case, we know that X cannot be 0. Fixing this, causes all the right
things to happen.
However, I see that the none of the op1_range entries are being called with a
relation. Presumably this was an oversight on Andrew's part, but can easily be
fixed.
Interestingly on this case, the VRP threader shouldn't even need to step up
here. VRP1 should have folded the conditional in BB8. The new evrp can
though. If I tweak range-ops, and call execute_early_vrp() from VRP1, evrp
folds the conditional and there's no need to thread.
Now before Andrew asks why evrp doesn't clean this up earlier (with the
range-ops tweak), it's because the IL is different. See my question about the
"a" present in earlier passes. ;-)
So...mine. I'll address all the issues pointed out.
