llvm dev - Jun 2019 - How to handle ISD::STORE when both operands are FrameIndex?

Hello.

After "Initial selection DAG" stage I get a DAG with node

t14: ch = store<(store 4 into %ir.p45, align 8, addrspace 1)> t10,
FrameIndex:i32<2>, FrameIndex:i32<3>, undef:i32

1. Where does it come from? Can I do anything to make it not appear?
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? Like

ch = StoreStackF<Mem:(store 4 into %ir.p45, align 8, addrspace 1)>
Register:%1, TargetFrameIndex:i32<3>, t10

Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190624/9c7d3784/attachment.html>

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

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.  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<mailto:kparzysz at
quicinc.com>   LLVM compiler development

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Gleb
Popov via llvm-dev
Sent: Monday, June 24, 2019 6:16 AM
To: LLVM Dev <llvm-dev at lists.llvm.org>
Subject: [EXT] [llvm-dev] How to handle ISD::STORE when both operands are
FrameIndex?

Hello.

After "Initial selection DAG" stage I get a DAG with node

t14: ch = store<(store 4 into %ir.p45, align 8, addrspace 1)> t10,
FrameIndex:i32<2>, FrameIndex:i32<3>, undef:i32

1. Where does it come from? Can I do anything to make it not appear?
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? Like

ch = StoreStackF<Mem:(store 4 into %ir.p45, align 8, addrspace 1)>
Register:%1, TargetFrameIndex:i32<3>, t10

Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190624/8690fa52/attachment.html>

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>