On 6/26/22 11:38, Aldy Hernandez wrote:
Thanks for pushing this.
The patch triggered a (known) regression on
g++.dg/warn/Wstringop-overflow-4.C. In the original submission I
mentioned I would XFAIL it, but forgot to do so. I have pushed the
attached patch.
Note that since this was the last user of EVRP, I think it is now safe
to remove its code, along with any options on params.def. Andrew, are
you OK with removing the legacy evrp code (gimple-ssa-evrp-analyze.*,
and any relevant bits)? Of course, the core VRP code would still
remain, as VRP1 still uses it.
I think that would be OK. We have not turned legacy evrp on for
anything for some time. And then any leftover bits that cant be removed
are probably being invoked from range-ops or somewhere else and we can
relocate them to where they belong and possibly better consolidate
them. At least go thru the excercise and produce the patch and see
what comes out. Maybe theres a surprise awaiting you :-) then we can
further discuss it.
Im currently working towards turning ranger on by deafult for VRP1, i
Just have a few issues to address. That'll still probably be a few weeks.
Andfrewe
Aldy
On Sun, Jun 26, 2022 at 1:08 AM Jeff Law <jeffreya...@gmail.com> wrote:
This is 99.99% Aldy's work. My only real contribution was twiddling one
MIPS specific test in response to a regression after adding this patch
to my tester.
In simplest terms, this patch converts DOM to use the Ranger
infrastructure rather than the EVRP infrastructure. I'd basically
approved it before Aldy went on PTO and it's been sitting in my tester
ever since. So I figured it was time to go ahead and push it.
Jeff
