On Tue, Sep 21, 2021 at 3:50 PM Andrew MacLeod <amacl...@redhat.com> wrote: > > On 9/21/21 9:32 AM, Richard Biener wrote: > > On Tue, Sep 21, 2021 at 2:57 PM Andrew MacLeod <amacl...@redhat.com> wrote: > >> On 9/21/21 2:14 AM, Richard Biener wrote: > >>> 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. > >> Different model, we dont have a lattice whereby we track state and move > >> form one to another.. we just track currently best known values for > >> everything and recalculate them when the old values are stale. We move > >> the edge to unexecutable when those values allow us to rewrite a branch > >> such that an edge can no longer be taken. everything else is executable. > >> Any values on an unexecutable edge are then considered UNDEFINED when > >> combined with other values.. > >> > >>> 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? > >> THe constructor for a ranger makes everything executable to start. > >> Calls the same routine VRP does. > >> > >> gimple_ranger::gimple_ranger () : tracer ("") > >> { > >> @@ -41,6 +42,7 @@ gimple_ranger::gimple_ranger () : tracer ("") > >> m_oracle = m_cache.oracle (); > >> if (dump_file && (param_evrp_mode & EVRP_MODE_TRACE)) > >> tracer.enable_trace (); > >> + set_all_edges_as_executable (cfun); > >> } > > Ah, I see. I had the impression that with ranger we can now > > do a cheap query everywhere on the range of an SSA name. But then > > the above is O(CFG size)... > > One of the reasons I'd like to see it persistent :-) We could > alternatively add another new one, something like EDGE_NEVER_EXECUTED > which is cleared by default when created and only ranger/other > interested passes utilize it and it is kept persistent. Just seems > more appropriate to "fix" the current flag. I took a quick look at that, > but it seemed like one or more of the propagation passes may use the > flag for other nefarious purposes. It would require fixing everyone to > maintain the value properly. > > Queries are still "cheap", but there are varying amounts of lookups > and allocations that are done. If the lack of a persistent EXECUTABLE > edge flag continues, I may make some further tweaks and make it > sensitive to whether EXECUTABLE is to be looked at or not and perhaps > only have the VRPs initiate that. I prefer avoiding different modes > when possible tho. > > Currently most/all uses of ranger are instantiated and used for the > duration of a pass, so the O(cfg) is pretty minimal with all the CFG > traversing and caching required.
Btw, there's auto_edge_flag (fun) that gets you a new flag allocated and it's supposed to be cleared on all edges (but I don't think we actually verify that - I suppose we should). The downside is you have to clear it after use - but it would in theory be possible to elide that by keeping a set of "dirty" flags and only clear all of those when we run out of non-dirty free flags. Richard. > > > > > I guess I'm confusing something - but yes, clearly in a ranger VRP "pass" > > that all sounds OK. > > > > Richard. > > >