Gleb Popov via llvm-dev
2019-Jun-24 11:15 UTC
[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: <lists.llvm.org/pipermail/llvm-dev/attachments/20190624/9c7d3784/attachment.html>
Tim Northover via llvm-dev
2019-Jun-24 12:08 UTC
[llvm-dev] How to handle ISD::STORE when both operands are FrameIndex?
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.
Krzysztof Parzyszek via llvm-dev
2019-Jun-24 12:14 UTC
[llvm-dev] How to handle ISD::STORE when both operands are FrameIndex?
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: <lists.llvm.org/pipermail/llvm-dev/attachments/20190624/8690fa52/attachment.html>
Gleb Popov via llvm-dev
2019-Jun-25 05:25 UTC
[llvm-dev] How to handle ISD::STORE when both operands are FrameIndex?
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: <lists.llvm.org/pipermail/llvm-dev/attachments/20190625/e17b955e/attachment.html>
Reasonably Related Threads
- How to handle ISD::STORE when both operands are FrameIndex?
- How to handle ISD::STORE when both operands are FrameIndex?
- How to handle ISD::STORE when both operands are FrameIndex?
- How to finalize instruction lowering after register allocation.
- Different SelectionDAGs for same CPU