On 10/28/22 10:14, Richard Biener wrote:
Am 28.10.2022 um 15:59 schrieb Andrew MacLeod <amacl...@redhat.com>:
On 10/28/22 09:46, Richard Biener wrote:
On Fri, Oct 28, 2022 at 3:43 PM Andrew MacLeod <amacl...@redhat.com> wrote:
On 10/28/22 03:17, Richard Biener wrote:
On Wed, Oct 26, 2022 at 4:24 PM Andrew MacLeod <amacl...@redhat.com> wrote:
Figured I would ask what you guys think of making ranger the default for
the VRP1 pass now.
With partial equivalences and the other bits I checked in the past few
weeks I'm not aware of much that the legacy VRP pass gets that ranger
doesn't. The only exception to that which I am aware of is the trick
played with the unreachable edges to set global ranges, but that is done
in the DOM passes now anyway... so it just happens slightly later in the
optimization cycle.
Note DOM should go away at some point. Why can this not happen during
ranger driven VRP?
I have been working on that for the last 2 days. Turns out VRP1 can
remove builtin_unreachable from the
if (X)
__builtin_unreachable ()
idiom and set the appropriate global ranges, but it has to leave those
with 2 ssa-names:
if (a_1 != b_2)
__builtin_unreachable()
until the second pass of VRP or we lose the relationship between a_1 and
b_2. That triggers some failures. Specifically a vectorizor fail
because it cant be sure that the start and end point are not the same
without the condition in the IL. Trying to store global relations over
multiple passes would be problematic at this stage of development, so I
don't see a problem with leaving it that way.
Hmm, I don't remember VRP1 doing anything special with the above though?
Did it somehow propagate the (un!)conditional equivalence?
So as I looked at builtin_unreachable(), it was very adhoc. That one of the
roots of that artificial testcase in the PR I opened. Cascading calls were not
being handled in a consistent way. VRP1 removed some, dom removed some.. they
just kind of disappeared at some point, but not consistently. The PR that Uli
opened that Aldy fixed, I could make fail again with minor adjustments to the
conditions. So I worked on a consistent approach.
My guess is the old range stored globally for that case for a_1 was probably
~[b_2, b_2] meaning it was carried in the range. Until we have an overall
global relation tracker, we can't represent that across passes.
The global ranges were never symbolic, this was at most used during VRP itself.
Ah. Just took a closer look at what use to happen.
legacy vrp1 never removed the unreachable call, it hung around until the
threadfull2 ran just before vrp2. The testcase was an artificial
vectorizing test with an infinite loop and unreachable in the final
block. Just part of the inconsistent removal :-P:
Andrew
