> It can't be included in GCC until binutils is updated. Given the nature > of this capability it may be necessary to conditionalize using this > capability based on whether or not the assembler has the proper support.
Is it necessary to add an option for control optimization? Or do you have any ideas? > > +(define_insn "base_idx_shxadd<X:MODE>" > > + [(set (match_operand:X 0 "register_operand" "=r") > > + (unspec:X > > + [(ashift:X (match_operand:X 1 "register_operand" "r") > > + (match_operand:QI 2 "imm123_operand" "Ds3")) > > + (match_operand:X 3 "register_operand" "r") > > + (match_operand:X 4 "symbolic_operand" "")] > > + UNSPEC_BASE_IDX_ADD))] > > + "TARGET_ZBA" > > + "sh%2add\t%0,%1,%3,%%base_idx_add(%4)" > > + [(set_attr "type" "bitmanip") > > + (set_attr "mode" "<X:MODE>")]) > We really shouldn't need to be using UNSPECs here. It's also unclear > to me what the assembler & linker are going to do with this 4-operand > shadd. If it's going to expand to multiple instructions, then you're > going to need to adjust the length attribute. Similarly for the > 4-operand add you created in riscv.md<http://riscv.md>. I have forwarded the implementation of binutils to you. If possible, please help review it. > In your .cc file, you've introduced a whole new pass to create these > things. Please look closely at other code and try to avoid adding > another pass if it can be avoided. In many ways this reminds me a lot > of fold-mem-offsets, so you might want to look closely at that pass In fact, I also tried to do it in several stages, such as：RTL Expand/ COMBINE/fold-mem-offsets.cc<http://fold-mem-offsets.cc>， However, the changes were rather cumbersome and complex, so I finally decided to extract them separately for optimization. > If you're going to ultimately need a new pass, then it needs to follow > coding styles and guidelines. The formatting/style is *way* off in that > new pass. It's bad enough that I didn't really dive into the basic > implementation details. It's also worth noting that your mailer seems > to be double-spacing everything making the patch exceptionally hard to read. Sorry, as a new GCC developer, I'm learning the GNU style. Do you have any good recommended tools? I use the command: `git diff -U0 --no-color --cached HEAD | clang-format-diff -p1 -i`, but it formats some code that I haven't modified. > From: "Jeffrey Law"<[email protected]> > Date: Tue, Jun 30, 2026, 06:27 > Subject: Re: [PATCH] RISC-V: Add new relocation type for global array > accesses with non-constant indices > To: "翁丽琴"<[email protected]>, > "[email protected]"<[email protected]>, "Kito > Cheng"<[email protected]>, > "[email protected]"<[email protected]>, "Jan > Beulich"<[email protected]>, "庄秋彬"<[email protected]> > On 6/24/2026 5:45 AM, 翁丽琴 wrote: > > This optimization is mainly to explain the low address of ADDI to the > > memory offset of ld/st, reducing the low address calculation instructions > > > > RISC-V PSABI specification: > > https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/489 > > <https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/489> > > > > LLVM Implements: https://github.com/llvm/llvm-project/pull/185353 > > <https://github.com/llvm/llvm-project/pull/185353> > > > > ISSUS: https://github.com/llvm/llvm-project/issues/185586 > > <https://github.com/llvm/llvm-project/issues/185586> > At a high level we should have buy-in from Kito that this or something > very close to it is acceptable from a PSABI standpoint. > > It can't be included in GCC until binutils is updated. Given the nature > of this capability it may be necessary to conditionalize using this > capability based on whether or not the assembler has the proper support. > > > +(define_insn "base_idx_shxadd<X:MODE>" > > + [(set (match_operand:X 0 "register_operand" "=r") > > + (unspec:X > > + [(ashift:X (match_operand:X 1 "register_operand" "r") > > + (match_operand:QI 2 "imm123_operand" "Ds3")) > > + (match_operand:X 3 "register_operand" "r") > > + (match_operand:X 4 "symbolic_operand" "")] > > + UNSPEC_BASE_IDX_ADD))] > > + "TARGET_ZBA" > > + "sh%2add\t%0,%1,%3,%%base_idx_add(%4)" > > + [(set_attr "type" "bitmanip") > > + (set_attr "mode" "<X:MODE>")]) > We really shouldn't need to be using UNSPECs here. It's also unclear > to me what the assembler & linker are going to do with this 4-operand > shadd. If it's going to expand to multiple instructions, then you're > going to need to adjust the length attribute. Similarly for the > 4-operand add you created in riscv.md. > > In your .cc file, you've introduced a whole new pass to create these > things. Please look closely at other code and try to avoid adding > another pass if it can be avoided. In many ways this reminds me a lot > of fold-mem-offsets, so you might want to look closely at that pass. > > If you're going to ultimately need a new pass, then it needs to follow > coding styles and guidelines. The formatting/style is *way* off in that > new pass. It's bad enough that I didn't really dive into the basic > implementation details. It's also worth noting that your mailer seems > to be double-spacing everything making the patch exceptionally hard to read. > > Jeff > This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not an intended recipient of this message, please delete it and any attachment from your system and notify the sender immediately by reply e-mail. Unintended recipients should not use, copy, disclose or take any action based on this message or any information contained in this message. Emails cannot be guaranteed to be secure or error free as they can be intercepted, amended, lost or destroyed, and you should take full responsibility for security checking. 本邮件及其任何附件具有保密性质，并可能受其他保护或不允许被披露给第三方。如阁下误收到本邮件，敬请立即以回复电子邮件的方式通知发件人，并将本邮件及其任何附件从阁下系统中予以删除。如阁下并非本邮件写明之收件人，敬请切勿使用、复制、披露本邮件或其任何内容，亦请切勿依本邮件或其任何内容而采取任何行动。电子邮件无法保证是一种安全和不会出现任何差错的通信方式，可能会被拦截、修改、丢失或损坏，收件人需自行负责做好安全检查。
