On 10/22/26 11:02 AM, Jin Ma wrote:
Factor common RTL parsing out of the existing macro-fusion recognizers. Preserve aggressive destination overmatching before register allocation while checking real producer-consumer dependencies in both scheduling passes. Use parameterized arithmetic and memory classifiers so later fusion recognizers can share structural matching without duplicating microarchitecture-specific constraints. V5: Initial implementation. V6: Fixes and refinements: - Prefer pseudo identity over a hard-register mapping while pseudos can still be created. - Cache destination register numbers without changing preallocation destination overmatching. - Set the optional source output to NULL_RTX for an immediate LI. - Accept mode-specific zero constants as store sources. - Use move_type to classify soft-float memory moves carried by integer instructions as GPR accesses. - Query instruction length only for moves wider than a word. Ref: https://patchwork.sourceware.org/project/gcc/patch/[email protected]/ gcc/ChangeLog: * config/riscv/riscv-fusion.cc: Include insn-attr.h. (riscv_fuse_sets_p): New function. (riscv_set_extract_word_binary_p): Likewise. (riscv_regno): New function. Prefer pseudo identities while pseudos may still be created. (riscv_fuse_same_reg_p): Likewise. (riscv_fuse_same_dest_p): Rename from riscv_fusion_same_dest_p and handle hard-register SUBREGs. Preserve preallocation destination overmatching and optionally check the first-source dependency. (riscv_set_is_addiw_p): New function. (riscv_insn_is_mv_li_p): Likewise. (riscv_insn_is_addi_type_p): New function. Clear SRC0 for LI. (riscv_set_is_shift_p): Likewise. (riscv_set_is_slli_p): Likewise. (riscv_set_is_srli_p): Likewise. (riscv_set_is_srai_p): Likewise. (enum sched_fusion_type): New enum. (riscv_fusion_mem_info): New struct. (riscv_fuse_extract_address): New function. (riscv_fuse_mem_p): New function. Accept mode-specific zero stores and classify soft-float memory moves by move_type. (riscv_fuse_zext_common): Require RV64 and use the common helpers. (riscv_fuse_zextw): Update accordingly. (riscv_fuse_zextws): Likewise. (riscv_fuse_zexth): Likewise. (riscv_fuse_ldindexed): Use the common helpers. (riscv_fuse_expanded_ld): Likewise. (riscv_fuse_ldpreincrement): Likewise. Check the update dependency. (riscv_fuse_lui_addi): Reuse the ADDI matcher, check the source dependency, and reject zero-valued LUI patterns. (riscv_fuse_auipc_addi): Reuse the ADDI matcher and check the source dependency. (riscv_fuse_lui_ld): Use the common helpers. (riscv_fuse_auipc_ld): Likewise. Check the address dependency. (riscv_fuse_aligned_std): Use the common helpers. (riscv_fuse_bfext): Likewise. (riscv_fuse_b_alui): Likewise. gcc/testsuite/ChangeLog: * gcc.target/riscv/fusion-lui-addi-prera-rtl.c: New test.
First, for the riscv_fuse_b_alui and riscv_fuse_bfext; it's unclear if the design I'm aware of with these will ever be in users' hands, so I'm not going to lose any sleep if your changes over-fuse for that design. In fact, if your design doesn't fuse them, then I'd seriously consider eliminating them. I suspect you're over-fusion loads for that design as well, but again, let's not let that design slow things down any more so that I have already.
I probably would have split out some of the common helper things as NFC changes. I could have acked those pretty easily a while ago. I likely would have considered splitting up the recognizer simplifications -- just reading them this many is painful and error prone. That's really a note for the future. Just a couple comments below.
Given the age of this patch, how much stuff is queued up behind it and the fact that the design that (until now) has the most kinds of fusions implemented may not end up in users' hands, I'm inclined to ACK now. I'm slightly uncomfortable given the size of the patch, density of the changes and lack of general testing for fusion. But I guess we'll just have to work through those concerns.
So what I'd request is that you do a fresh test of your series and assuming things are good, go ahead and push. That should in turn unlock our ability to move forward on the GlobalFoundaries fusion work.
jeff
