[EMAIL PROTECTED] wrote on 02/06/2005 04:29:17: > Steven Bosscher <[EMAIL PROTECTED]>: > > > On Wednesday 01 June 2005 16:43, Canqun Yang wrote: > > > Hi, all > > > > > > I've taken a look on modulo-sched.c recently, and found > > > that both new_cycles and orig_cycles are imprecise. The > > > reason is that kernel_number_of_cycles does not take the > > > data dependences of insns into account as the DFA > > > scheduler does in haifa-sched.c. > > > > How does this affect the cycles computation? > > > > An insns is ready for schedule only when all the insns > it dependent on have already be scheduled. In haifa- > sched.c, there is a queue to hold the insns which are > ready for schedule. The code mentioned above is the part that decides if SMS did a better schedule or not and decides if to use the SMSed kernel or stay with the original kernel -- we don't want to spend more compile time on additional scheduling pass to make this more accurate (if this is what you are suggesting). A proper solution is to add a parameter to GCC that its purpose is to define what is "a good schedule" in means of kernel cycles. You even can disable this by saying that any kernel generated by SMS is better than the original. For example, if we add a parameter, like: --param sms-percent-from-orig=N. When N is 0 SMSed kernel will always be preferred over the original. The current implementation is similar to --param sms-percent-from-orig=100. > > To find how the data dependence affect the cycles > computation, the more simple way is to compare the > two versions of assembly code generated by GCC > respectively, one is generated by turning on '-fmodulo- > sched', the other not. Without SMS, the code in loop > has many stops ';;' to seperate the instrcutions which > have data dependence, while with SMS, though the > kernel code of the loop has more instructions, but > less stops ';;'. What are you suggesting here? > > > > When I manually hacked modulo-sched.c to ignore this test, I > > did see loops getting scheduled, but I also ran into ICEs in > > cfglayout. > > There are no ICEs for pi.f90, swim.f, and mgrid.f > according to my test. But, an internal compile error > of 'unrecognizable insn' is produced > by 'gen_sub2_insn' which explicitly minus 'ar.lc' when > swim.f and mgrid.f are being compiled. I have committed a fix for SMS so I am not sure if this what eliminates the ICEs Steven was seeing. Regarding the 'unrecognizable insn' due to gen_sub2_insn; I had an impression that it should generate the required register moves in order to perform the calculation, if this is not true then there should be a wrapper to this function that makes sure that we do the subtraction properly. This is not something specific to SMS, how do you generate a subtraction from ar.lc on IA-64? I suppose that there is a pattern that covers this and generates the appropriate RTL. Thus gen_sub2_insn should be using this pattern and it is not -- so this is our problem. Mostafa.
