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? > 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. I'm defering to Eric here. Richard. > Andrew > >
