On Tue, Sep 21, 2021 at 12:01 AM Andrew MacLeod via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > > The patch sets the EXECUTABLE property on edges like VRP does, and then > removes that flag when an edge is determined to be un-executable. > > This information is then used to return UNDEFINED for any requests on > un-executable edges, and to register equivalencies if all executable > edges of a PHI node are the same SSA_NAME. > > This catches up a number of the cases VRP gets that ranger was missing, > and reduces the EVRP discrepancies to almost 0. > > On a side note, is there any interest/value in reversing the meaning of > that flag? It seems to me that we could assume edges are EXECUTABLE by > default, then set a NON_EXECUTABLE flag when a pass determines the edge > cannot be executed. This would rpevent a number fo passes from having > to loop through all the edges and set the EXECUTABLE property... It > just seems backwards to me.
The flag is simply not kept up-to-date and it's the passes responsibility to make use of it (aka install a default state upon entry). To me not having EDGE_EXECUTABLE set on entry is more natural for optimistic propagation passes, but yes, if you do on-demand greedy processing then you need a conservative default. But then how do you denote a 'VARYING' (executable) state that may not drop back to 'CONSTANT" (not executable)? For optimistic propagation EDGE_EXECUTABLE set is simply the varying state and since we never clear it again there's no chance of oscillation. Richard. > Anyway, bootstrapped on x86_64-pc-linux-gnu with no regressions. pushed. > > Andrew >
