On Tue, 2020-05-19 at 09:09 +0200, Richard Biener wrote: > On Mon, May 18, 2020 at 8:13 PM Aldy Hernandez via Gcc-patches > <gcc-patches@gcc.gnu.org> wrote: > > We already moved the value_range class into its own class in the last > > release. I think it's time to move the value_range_equiv stuff into its > > own class, as it's a distraction from the VRP code. > > > > I've moved it to value-range-equiv.*, and gave it a semblance of order, > > by putting the constructors and setters at the beginning, the dumpers at > > the bottom, etc. > > > > No functional changes. > > > > OK for mainline? > > Just a note - I dislike spreading all the VRP code across so many files. > It gets harder and harder to find pieces that once were just in the single > tree-vrp.c file ... > > But I'm staying out of here as promised. > > It would be much more useful if, for example, the -Warray-bound > warning were split out from the "old" VRP code and put somewhere > else (preferably not another walk over the IL but combined with a > diagnostic pass already performing a EVRP dom walk). We've been looking at doing it as part of the path isolation code so that we can (conditionally) turn the out of range references into traps.
> > Likewise for the jump-threading bits. VRP jump threading should just go away. BUt that's blocked on getting the Ranger bits in which is what all this is leading up to. jeff
