On Wed, Sep 29, 2021 at 5:28 PM Jeff Law <jeffreya...@gmail.com> wrote: > > > > On 9/29/2021 9:20 AM, Andrew MacLeod via Gcc-patches wrote: > > On 9/29/21 4:43 AM, Richard Biener wrote: > >> On Tue, Sep 28, 2021 at 10:39 PM Andrew MacLeod <amacl...@redhat.com> > >> wrote: > >>> On 9/28/21 7:50 AM, Richard Biener wrote: > >>>> On Wed, Sep 15, 2021 at 10:46 AM Martin Liška <mli...@suse.cz> wrote: > >>>>> /* Unswitch single LOOP. NUM is number of unswitchings done; > >>>>> we do not allow > >>>>> @@ -269,6 +311,7 @@ tree_unswitch_single_loop (class loop *loop, > >>>>> int num) > >>>>> class loop *nloop; > >>>>> unsigned i, found; > >>>>> tree cond = NULL_TREE; > >>>>> + edge cond_edge = NULL; > >>>>> gimple *stmt; > >>>>> bool changed = false; > >>>>> HOST_WIDE_INT iterations; > >>>>> @@ -311,11 +354,12 @@ tree_unswitch_single_loop (class loop *loop, > >>>>> int num) > >>>>> bbs = get_loop_body (loop); > >>>>> found = loop->num_nodes; > >>>>> > >>>>> + gimple_ranger ranger; > >>>> ISTR constructing/destructing ranger has a non-negligible overhead - > >>>> is it possible > >>>> to keep it live for a longer time (note we're heavily modifying the > >>>> CFG)? > >>> > >>> There is some overhead.. right now we determine all the imports and > >>> exports for each block ahead of time, but thats about it. We can make > >>> adjustments for true on demand clients like this so that even that > >>> doesnt happen. we only do that so we know ahead of time which ssa-names > >>> are never used in outgoing edges, and never even have to check those. > >>> Thats mostly an optimization for heavy users like EVRP. If you want, I > >>> can make that an option so there virtually no overhead > >>> > >>> More importantly, the longer it remains alive, the more "reuse" of > >>> ranges you will get.. If there is not a pattern of using variables > >>> from earlier in the program it wouldnt really matter much. > >>> > >>> In Theory, modifying the IL should be fine, it happens already in > >>> places, but its not extensively tested under those conditions yet. > >> Note it's modifying the CFG as well. > > bah, thats what I meant. as long as the IL is changed and CFG > > updated to match, it should in theory work. And as long as existing > > SSA_NAMEs dont have their meaning changes.. ie reusing an SSA_NAME to > > have a different definition is likely to cause problems without > > telling ranger that an SSA_NAME is now different. > There is an API somewhere which resets the global information that we > call for these scenarios. But that assumes we know when an name is > going to be reused or moved to a point where the global information > isn't necessary accurate anymore. It's not heavily used as these cases > are relatively rare. > > The nastier case is when we release an SSA_NAME because it was dead > code, then later re-cycle it. If we're going to have Ranger instances > live across passes, then that becomes a much bigger concern.
For the case at hand there shouldn't be any transforms invalidating ranges on existing SSA names - we possibly place additional conditions and thus refine existing ranges though, and we rely on that info to be used. Since we repeatedly transform a single loop re-setting ranger like Martin did might be necessary for those to be picked up. Richard. > Jeff >
