https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #22 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 8 Nov 2021, hubicka at kam dot mff.cuni.cz wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997 > > --- Comment #21 from hubicka at kam dot mff.cuni.cz --- > > to also allow to thread through a loop path not crossing the latch but > > at least for the issue of "breaking loops" the loops_crossed stuff shouldn't > > be necessary. It might still prevent us from doing such transforms when > > it involves peeling. > > I am not sure what is the set of tranforms we want to forbid in general. > I think main situation we want to prevent is turning single-entry loop > to irreducible loop by forwarding loop entry edges differently. > > For that it should be safe to trhead if the path enters a loop and later > leaves. For that we need to keep track of loops we entered in stack and > pop them when we leave it and check that stack is empty at the end. (or > do stackless bookeeping but it may happen that we start in one loop, > leave it and then enter different loop and stop in it which is stil > unsafe so just comparing loop nest of entry and exit block is not right > thing to do) We verify that by simply looking at the loop depth relation of the entry and exit of the path. > It seems to me that it should be also OK to thread if we thread all > entry edges to the loop (in particular if it is only one) which should > be easy to check by looking into other edges entering the path being > threaded and checking that they are from loop and not from outside > (since the outside edges will keep the old path alive and we end up with > duplicated entry point). > > I may miss something obvious, but I would say that all other threads > involving loops should be fine and better informed than peeling since > threader knows that the path in question is special. The issue is that the threader does not update loop info and it's important to keep things like ->simdlen associated to the correct loop and without distorting the loop in a way that invalidates such info (pre loop optimization). The forward threader contained some code to keep loops up-to-date but as usual the backwards threader is just broken with respect to this. So yes, any threading that enters and leaves a loop is OK, but a threading that rotates or peels a loop [not completely] is not trivially so.
