On Mon, Sep 17, 2018 at 4:50 PM Jeff Law <l...@redhat.com> wrote: > > This is a relatively minor cleanup that I should have caught last cycle, > but somehow missed. > > We have two structures TO_REMOVE_EDGES and TO_UPDATE_SWITCH_STMTS which > are used by the VRP/EVRP code to record edges to remove and switch > statements that need updating. > > They are currently implemented as globals within tree-vrp.c with an > appropriate extern within tree-vrp.h. > > The code to walk those vectors was only implemented in VRP, but we can > (and do) add to those vectors within EVRP. So EVRP would detect > certain edges as dead or switches that were needed simplification, but > they were left as-is because EVRP never walked the vectors to do the > necessary cleanup. > > This change pushes the vectors into the vr_values structure. They're > initialized in the ctor and we verify they're properly cleaned up in the > dtor. This obviously avoids the global object carrying state, but also > catches cases where we record that an optimization was possible but > failed to update the IL appropriately. > > As a side effect, we don't need to bother with initializing and wiping > EDGE_IGNORE for jump threading in VRP. We just mark the appropriate > edges at the same time we put them in TO_REMOVE_EDGES within vr_values. > > vrp113.c is an example of where EVRP detected optimizations should be > possible, but failed to update the IL. Given the test really wanted to > check VRP's behavior, I've disabled EVRP for that test. > > Bootstrapped and regression tested on x86_64-linux-gnu. > > OK for the trunk?
OK. Maybe you can duplicate vrp113.c to also have a EVRP testing variant of this functionality? Thanks, Richard. > Jeff >