> 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.
>
> It appears that leaving those until VRP2 works fine... testsuite currently
> running tho ;-)
>
> Andrew
>
