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

[Krzysztof Parzyszek via llvm-dev]

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>