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

[Tim Northover via llvm-dev]

On Tue, 25 Jun 2019 at 06:26, Gleb Popov via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>> 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 looks more like it's storing *to* a FrameIndex than storing a
FrameIndex, but it actually shouldn't matter. The same sequence of
events I described would happen except the selected bare FrameIndex
would feed into the pointer operand of the store rather than the value
operand.

If you had both kinds of pattern (storing an FI and storing to an FI)
and wanted one to have priority you can add a "let AddedComplexity =
10" or similar to one of them so that LLVM favours it when both would
apply.

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

"Materializing" would probably have been a less ambiguous choice of
words. I wouldn't expect a load instruction on most architectures.

> And what's "STORE"? Is it somehow different from "store"?

On most targets in LLVM the implemented instruction names are written
in capital letters (mostly): ADDrm, MULrr, STRXrs. The STORE there was
meant to represent a target-specific store instruction (like you'd get
on the RHS of a Pat instantiation) without committing to any
particular architecture.

Could you describe what *is* happening for you, BTW? Maybe with an
"llc -debug" log on a simple example. We might be able to give more
specific advice with the actual error.

Cheers.

Tim.