On 6/6/24 8:51 PM, Jin Ma wrote:
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)
;; 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)I'd really love to see a testcase here, particularly since I'm still
having trouble understanding the code you're currently getting vs the
code you want.
Furthermore, I think I need to understand the end motivation here. I
always think of fusion priority has bringing insns consecutive so that
peephole pass can then squash two more more insns into a single insn.
THe canonical case being load/store pairs.
If you're trying to generate pairs, then that's fine. I just want to
make sure I understand the goal. And if you're trying to generate pairs
what actually can be paired? I must admit I don't have any notable
experience with the thead core extensions.
If you're just trying to keep the instructions consecutive in the IL,
then I don't think fusion priorities are a significant concern. Much
more important for that case is the fusion pair detection (which I think
is about to get a lot more attention in the near future).
Jeff
