Re: RFC - VRP1 default mode

[Andrew MacLeod <amacleod@redhat.com>]

On 10/28/22 03:17, Richard Biener wrote:
> On Wed, Oct 26, 2022 at 4:24 PM Andrew MacLeod <amacleod@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.

bultin_unreachables() from switches get removed during the second pass 
of switch-conversion... which I presume remains OK.

Anyway, thats pretty much under control.  Patch probably coming later today.



>> There is one test case that needs adjustment for
>> that which was just checking for a mask in DOM2
>> (gcc.dg/tree-ssa/pr107009.c).   At this point I have not aware of
>> anything that Id be concerned about, and the testsuite seems to run
>> cleanly.
> Did you enable Ada?  The only feature I don't see implemented is
> symbolic range handling which boils down to general base + constant offset
> range endpoints (that's what symbolic ranges allow).  That area was
> specifically improved to optimize range checks emitted by the Ada frontend
> but IIRC also applies to fortran -frange-check (not sure about test coverage
> of that).
I get a clean testsuite run configured and bootstrapped with

    --enable-languages=c,c++,go,fortran,ada,obj-c++,jit --enable-host-shared

Is there a PR or specific tests in either fortran or ada for those 
improvements? ie, something specific I should check for? Part of rangers 
point is to be able to do symbolic relationships without storing the 
symbolic in the range, just picking it up from the IL as needed.

Andrew