On Thu, 21 Jun 2018 at 02:07, ComputerFreak via llvm-dev
<[hidden email]> wrote:
> 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:
On Thu, 21 Jun 2018 at 08:27, ComputerFreak <[hidden email]> wrote:
> 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
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