> 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. >
I'm sorry I did not split this into smaller patches, which made the review harder. I have limited experience organizing patches like this and will take more care with splitting them in future. > 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 Thank you for the ACK. I understand your concerns about test coverage and will thoroughly retest the entire series. Thanks, Jin
