On Tue, Sep 21, 2021 at 8:09 AM Richard Biener <richard.guent...@gmail.com> wrote: > > 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.
Btw, I fail to see how the patch makes ranger assure a sane initial state of EDGE_EXECUTABLE (or make its use conditional). Is the code you patched not also used on-demand? That is, are you sure you're not running into wrong-code issues if you for example in passes.c:execute_one_pass right before passes initialize EDGE_EXECUTABLE to a random state on each edge of the function? Richard. > Richard. > > > Anyway, bootstrapped on x86_64-pc-linux-gnu with no regressions. pushed. > > > > Andrew > >
