This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: mips SB-1 DFA scheduler

Jim Wilson wrote:

On Thu, 2004-03-04 at 06:57, Paul Koning wrote:

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.

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.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]