Re: fix scheduling compile time regression

[Richard Henderson <rth at redhat dot com>]

On Tue, Jan 29, 2002 at 03:27:51PM -0700, law@redhat.com wrote:
> In message <20020129141953.A8147@redhat.com>, Richard Henderson writes:
>  > Irritatingly, my test case isn't particularly generic.  The badness
>  > happens because of a curiousity in the way alpha function calls are
>  > built.  I'm certain that the problem could arise on other targets,
>  > but I'd have to work harder to make it happen.
> What's the underlying issue?

Iterative buildup of the clobber/use lists.

We had a USE of the pic register on the call insn (because the ABI
requires that we pass it along to the called function).  But regclass
had decided that the pic register wasn't the pic register without
flag_pic set.  So every call insn was listed as both a user and
clobberer of the pic register.

Clobbers don't normally depend on one another, because you want to
have the freedom to reorder them.  This is particularly important
for x86 because most arithmetic clobbers the flags register.  But
since they don't depend on each other, you can never flush the use list,

So what you wind up with is that every call depends on every call
that preceeds it.  Multiply by 5000 and you waste an enourmous 
amount of time and memory.

My solution is to eventually decide that the lists have gotten too
long.  At that point, you designate the next clobber insn to be a
scheduling barrier and make it depend on all the preceeding clobbers
and all the preceeding uses.  At which point you can flush the lists
and have subsequent insns depend only on the barrier insn.

> PA64 certainly has had some problems with sched2 taking far too long.
> WHen I last looked at it, I speculated that the problem was related
> to dependencies at call sites during sched2.

Note that I've also tweeked how regclass treats the pic register.
It now treats the pic regnum as the pic register whenever it is fixed,
not merely when flag_pic.  Which also prevents this specific alpha
problem from ocurring, but I thought fixing the underlying problem
in sched was important.

So if the pa64 problem is similar to the alpha problem (and it might
well be) it might be doubly cured.  One way to tell for certain is
to try the 5000 call test case with yesterday's vs today's compiler.


r~