On 9/19/23 08:56, Richard Biener wrote:
On Mon, Sep 18, 2023 at 3:48 PM Andrew MacLeod <amacl...@redhat.com> wrote:
OK.
I dont see anything in the early VRP processing now that would allow a
later pass to remove the unreachable unless it does its own analysis
like DOM might do.
Isn't it as simple as
if (i_2 > 5) __builtin_unreachable ();
registering a global range of [6, INF] for i_2 and then the next time
we fold if (i_2 > 5) using range info will eliminate it? Yes, historically
that required VRP or DOM since nothing else looked at ranges, not
sure how it behaves now given more match.pd patterns do look
at (global) ranges.
if we set the range yes. What I meant was in the cases where we decide
it can't be removed, we do NOT set the range globally in vrp1 now. This
means unless some other pass determines the range is [6, +INF] the
unreachcable call will remain in the IL and any ranger aware pass will
still get the contextual range info resulting from the unreachable. We
were sometimes removing the unreachable without being able to update
every affected global/future optimization opportunity, which this fixes.
Hopefully :-) Its certainly much better at least.
In theory, if inlining were aware of global ranges and propagated them,
we could also now remove these some of these unreachables in EVRP rather
than VRP1... as I think we're now sure there is no benefit to keeping
the unreachable call when we remove it.
In any case, thanks for the explanation and OK for the patch.
Will check it in shortly.
Andrew
