The thing is, llvm Store Format gets Register and Pointer Type Operand.
beside this, RISC-V Store Instruction takes source Register, Base Register and offset immediate type. So this takes 3 leafs.
In this case, should I make new SelectionDAG Node in this case?
If you're trying to write a pattern to select that kind of store, you
write a more complicated arithmetic pattern instead of a simple
register for the pointer on the source side. It's in RISCVInstrInfo.td
around lines 731 onwards, a little obfuscated by the multiclasses but
a simple example would be:
Notice that where the "store" itself has declared it takes a pointer
we've got a more complex "add" expression which describes how the
RISC-V store instruction calculates its address.
or use BuildMI Instruction to add new Register?
I'm afraid I don't understand how this could help.
So this means I can match the Node with my personal Node Pattern?
If I understand you right, yes.
Im confusing on this because the LLVM has their own store pattern. So I first thought I have to match the original pattern first and then change into my own pattern.
Like matching
store i32 3, i32* %ptr
first, and then change that %ptr value into register and immediate value.
The IR you'd be matching would actually be something like this
When LLVM converts these two instructions to SelectionDAG they'll
become a store node that uses an add node as its pointer
(getelementptr is really just a fancy way to offset pointers). I've
attached a screenshot of the output from "llc -view-isel-dags" on a
simple test program; notice that the store node (labeled t8) points to
an add.
When you write the pattern I gave in my last e-mail that's what you're
telling the instruction selector to look for: (store GPR:$rs2, (add
GPR:$rs1, simm12:$imm12)). The $rs2 matches t5, $rs1 matches t2 (GPRs
can match anything of the right type), and the $imm12 matches the t3
(the Constant<168>).
