public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* more complicated scheduler question
@ 2001-10-15 15:15 Dale Johannesen
  0 siblings, 0 replies; only message in thread
From: Dale Johannesen @ 2001-10-15 15:15 UTC (permalink / raw)
  To: gcc

I have a block that looks like this:

...
x = y/z;
a = b/c;
...

and so on, with 20 or so FP divides, and none of the memory references
dependent.  On a machine with a single FP divide unit, it's obvious to
a human that the speed of this block is going to depend on how fast
you can do those divides; you want to start doing them as soon as
possible.  The Haifa scheduling algorithm doesn't do that.  All the
loads get the same, high priority, higher than that of the divides,
so it will schedule all the loads ahead of all the divides if
resources permit.  Basically the "critical path" algorithm has problems
when there are multiple, parallel critical paths.  The real "critical
path" here is keeping the FP unit occupied, but the scheduler never
figures that out.

I've tried a number of things to fix this, and have something that seems
to improve the behavior overall on the target and benchmarks I'm
interested in.  But this is neither general nor elegant, nor a win in
all cases for that matter, and anyway it seems to me the problem is more
generic than target-dependent.  So I thought I'd see if anyone here had
a suggestion; I know people have worked on this scheduler longer than
I have.

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2001-10-15 15:15 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-10-15 15:15 more complicated scheduler question Dale Johannesen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).