Re: [RFA] Minor cleanup to VRP/EVRP handling of deferred edge/switch optimization

[Richard Biener <richard dot guenther at gmail dot com>]

On Mon, Sep 17, 2018 at 4:50 PM Jeff Law <law@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
>