[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

["hubicka at kam dot mff.cuni.cz" <gcc-bugzilla@gcc.gnu.org>]

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