[llvm-dev] How to handle ISD::STORE when both operands are FrameIndex?

[Gleb Popov via llvm-dev]

On Mon, Jun 24, 2019 at 4:08 PM Tim Northover <t.p.northover at gmail.com>
wrote:

> 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.
>

Aha, thanks.


> > 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
two FrameIndicies.


That's probably
> 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.
>
> Cheers.
>
> Tim.
>



On Mon, Jun 24, 2019 at 4:14 PM Krzysztof Parzyszek <kparzysz at quicinc.com>
wrote:

> 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
me.

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...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190625/e17b955e/attachment.html>