https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2024-04-15
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC| |law at gcc dot gnu.org
--- Comment #3 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Right. So what I'm most interested in are the scheduler decisions as most
likely IRA/LRA are simply stuck dealing with a pathological conflict graph
given the number of register available. ie, sched1 is the root cause.
Given the size of the problem and the fact that we have register pressure
sensitive scheduling enabled, I don't really think it's related to the issues
Andrew linked or the others I've looked at in the past. But we're going to
have to dive into those sched1 dumps to know for sure.
Vineet, do we have this isolated enough that we know what function is most
affected and presumably the most impacted blocks? If so we can probably start
to debug scheduler dumps.
There's a flag -fsched-verbose=N that gives a lot more low level information
about the scheduler's decisions. I usually use N=99. It makes for a huge
dump, but gives extremely detailed information about the scheduler's view of
the world. It's going to be big enough that bugzilla might balk at attaching
the file, even after compression.
I'm going to go ahead and confirm given Robin's seen the same behavior on this
benchmark.
