This is the mail archive of the
mailing list for the GCC project.
Re: RFC: mips SB-1 DFA scheduler
Jim Wilson wrote:
On Thu, 2004-03-04 at 06:57, Paul Koning wrote:Yes, probably I should change the description of the hook using more
"scheduling freedom" without any details and giving recommended value
(equal to issue rate which I found for Itanium and Sparc). The details
are too complicated. Actually, the algorithm can look at all queue (of
any length) at some conditions (when insns in the queue can not be
issued) if the value >=2 and we had no constraint max_look_ahead_tries.
My best interpretation is that this hook says how far to look ahead in
the queue of ready instructions to find the ones that will be issued
this cycle. And it seems pretty obvious that you can't rearrange
instruction issue for a quad issue machine unless you look at
substantially MORE than 4 ready instructions, right? Otherwise you're
basically just issuing FIFO. That can't be right. So what am I
I don't really see much benefit to investigating this issue any farther,
since my use is consistent with other targets, and I am not aware of any
problems with my use of this hook. I may spend some time playing with
this number to see if it affects performance.
If it is just the comment that you find confusing, then I can fix that.
I could replace the current wording with the "scheduling freedom"
wording that is found in other files.
The truth is that the value is a heuristic parameter. Because the
algorithm is another heuristic (besides many others in the insn
scheduler), I can not say that the more value is, the better schedule
is. Too big parameter (besides making the algorithm slower) can
decrease importance of critical path length heuristic and also result in
too many specualtive insn moves. The algorithm itself is a compromise
between critical path based scheduling and scheduling based on issue as
many insns as possible on each cycle. Sometimes the critical path based
one works better than issuing as many insns as possible on each cycle,
sometimes not. This approach works better at least for
Itanium/sparc/sh4. The parameter values for them have been choosen
empirically. So I think that the right approach is to use benchmarking
to choose the value.
I believe Jim has choosen the right (recommended) value.