[llvm-dev] How to handle ISD::STORE when both operands are FrameIndex?
Gleb Popov via llvm-dev
llvm-dev at lists.llvm.org
Mon Jun 24 22:25:31 PDT 2019
On Mon, Jun 24, 2019 at 4:08 PM Tim Northover <t.p.northover at gmail.com>
> On Mon, 24 Jun 2019 at 12:16, Gleb Popov via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > 1. Where does it come from? Can I do anything to make it not appear?
> It comes from something like:
> %ptr = alloca i8
> %var = alloca i8*
> store i8* %ptr, i8** %var
> and in general it's not possible to eliminate the combination.
> > 2. If not, how do I change it so that the operand being stored would be
> first loaded into a register, and that register would be used instead?
> While the store is being selected LLVM will just treat the value being
> stored as a generic pointer-width integer unless you have written a
> specific pattern for storing a FrameIndex somewhere.
Actually, this is exactly my case. I have a pattern that looks like
(store_stack IntRegs:$reg, FIOperand:$i)
It worked for me when first operand was a register and now I stumbled upon
> what you want so no need to change anything.
> After that, LLVM will try to select the FrameIndex itself (which
> you'll need to support anyway so that you can pass a pointer to a
> local variable between functions).
> Generally this seems to be handled by XYZISelDAGToDAG.cpp, which
> converts an ISD::FrameIndex into an appropriate arithmetic instruction
> that can offset from SP. That gets lowered to actual known offsets
> later on, in exactly the same way loads and stores are.
> It's probably done in C++ rather than TableGen because the operands of
> these resulting instructions often look pretty weird (for example a
> TargetFrameIndex instead of a register). That's mostly speculation
> though, I haven't tried to write a bare frameindex pattern.
On Mon, Jun 24, 2019 at 4:14 PM Krzysztof Parzyszek <kparzysz at quicinc.com>
> FrameIndex values come from objects that are still allocated on the stack
> at the time of the SDAG construction. In your case it seems that the
> address and the value to store are both on the stack. You don’t need to do
> anything in particular with it. If you have a selection pattern of form
> “(store RegClassA:$Addr, RegClassB:$Val), (STORE $Addr, $Val)”, then it
> will force loading both, Addr and Val into registers.
You mean, LLVM will automagically generate loads? This isn't happening for
And what's "STORE"? Is it somehow different from "store"?
I think someone has added a pattern to match frame index in patterns as
> well (it didn’t use to be possible and you had to use ComplexPattern), so
> your pattern can handle that directly too.
> Krzysztof Parzyszek kparzysz at quicinc.com LLVM compiler development
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev