I am very sorry that I did not check the commit information carefully. The statement is somewhat inaccurate.
> When the insn 1 and 2, 3 and 4 can be fusioned, then there is the > following sequence: > > ;; insn | > ;; 1 | sp=sp-0x18 > ;; + 2 | [sp+0x10]=ra > ;; 3 | [sp+0x8]=s0 > ;; 4 | [sp+0x0]=s1 > The fusion priority of the insn 2, 3, and 4 are the same. According to > the current algorithm, since abs(0x10-0x8)<abs(0x10-0x0), the insn 2 > is followed by the insn 3. It is obviously unreasonable to do so. > > Therefore, when we issue the insn 3 and 4, we should consider the fusion > priority of the insn 1 instead of the insn 2. And the final instruction > sequence is as follows: > ;; insn | > ;; 1 | sp=sp-0x18 > ;; + 2 | [sp+0x10]=ra > ;; 4 | [sp+0x8]=s1 > ;; + 3 | [sp+0x0]=s0 > > gcc/ChangeLog: > * haifa-sched.cc (rank_for_schedule): Likewise. When the insn 1 and 2, 4 and 3 can be fusioned, then there is the following sequence: ;; insn | ;; 1 | sp=sp-0x18 ;; + 2 | [sp+0x10]=ra ;; 3 | [sp+0x8]=s0 ;; 4 | [sp+0x0]=s1 The fusion priority of the insn 2, 3, and 4 are the same. According to the current algorithm, since abs(0x10-0x8)<abs(0x10-0x0), the insn 2 is followed by the insn 3. It is obviously unreasonable to do so. Therefore, when we issue the insn 3 and 4, we should consider the fusion priority of the insn 1 instead of the insn 2. And the final instruction sequence is as follows: ;; insn | ;; 1 | sp=sp-0x18 ;; + 2 | [sp+0x10]=ra ;; 4 | [sp+0x0]=s1 ;; + 3 | [sp+0x8]=s0 gcc/ChangeLog: * haifa-sched.cc (rank_for_schedule): Likewise. --- Sorry again for adding trouble to the review. Thanks Jin
