https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #23 from hubicka at kam dot mff.cuni.cz --- > We verify that by simply looking at the loop depth relation of > the entry and exit of the path. Which seem wrong for the path leaving loop and entering another... > > > 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. I see. Did not think of that. Perhaps something to solve incrementally next stage1 Honza
