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
