<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 25, 2019 at 9:59 AM Tim Northover <<a href="mailto:t.p.northover@gmail.com">t.p.northover@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 25 Jun 2019 at 06:26, Gleb Popov via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>> While the store is being selected LLVM will just treat the value being<br>
>> stored as a generic pointer-width integer unless you have written a<br>
>> specific pattern for storing a FrameIndex somewhere.<br>
><br>
> Actually, this is exactly my case. I have a pattern that looks like<br>
><br>
> (store_stack IntRegs:$reg, FIOperand:$i)<br>
><br>
> It worked for me when first operand was a register and now I stumbled upon two FrameIndicies.<br>
<br>
That looks more like it's storing *to* a FrameIndex than storing a<br>
FrameIndex, but it actually shouldn't matter. The same sequence of<br>
events I described would happen except the selected bare FrameIndex<br>
would feed into the pointer operand of the store rather than the value<br>
operand.<br>
<br>
If you had both kinds of pattern (storing an FI and storing to an FI)<br>
and wanted one to have priority you can add a "let AddedComplexity =<br>
10" or similar to one of them so that LLVM favours it when both would<br>
apply.<br>
<br>
>> 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.<br>
><br>
> You mean, LLVM will automagically generate loads? This isn't happening for me.<br>
<br>
"Materializing" would probably have been a less ambiguous choice of<br>
words. I wouldn't expect a load instruction on most architectures.<br>
<br>
> And what's "STORE"? Is it somehow different from "store"?<br>
<br>
On most targets in LLVM the implemented instruction names are written<br>
in capital letters (mostly): ADDrm, MULrr, STRXrs. The STORE there was<br>
meant to represent a target-specific store instruction (like you'd get<br>
on the RHS of a Pat instantiation) without committing to any<br>
particular architecture.<br>
<br>
Could you describe what *is* happening for you, BTW? Maybe with an<br>
"llc -debug" log on a simple example. We might be able to give more<br>
specific advice with the actual error.<br></blockquote><div><br></div><div>Sigh. I'm completely confused and lost. Thanks for bearing with me.</div><div><br></div><div>Here's my current definition:</div><div><br></div><div>def AddrFI: ComplexPattern<i32, 1, "SelectAddrFI", [frameindex], []>;<br><br>class StackAddress : CodePatPred<[{<br>  return cast<MemSDNode>(N)->getAddressSpace() == 1;<br>}]>;</div><div><br></div><div>class StoreFrag<SDPatternOperator op> : PatFrag <<br>  (ops node:$value, node:$ptr), (op node:$value, node:$ptr)<br>>;<br><br>class StackStore <SDPatternOperator op> : StoreFrag <op>, StackAddress;<br><br>def store_stack : StackStore<store>;</div><div><br></div><div>def StoreStackF : InstRI<2, (outs), (ins IntRegs:$reg, i32imm:$i),<br>  Â  Â  Â  Â  Â  Â  Â  Â  Â  "storestackf $reg, [$i]", [(store_stack i32:$reg, AddrFI:$i)]>;</div><div><br></div><div>I'm puzzled why despite having "IntRegs:$reg" in ins list, it still matches FrameIndex:</div><div><br></div><div>SEL: Starting selection on root node: t14: ch = store<(store 4 into %ir.p45, align 8, addrspace 1)> t10, FrameIndex:i32<2>, FrameIndex:i32<3>, undef:i32<br>ISEL: Starting pattern match<br>  Initial Opcode index to 4<br>  Morphed node: t14: ch = StoreStackF<Mem:(store 4 into %ir.p45, align 8, addrspace 1)> FrameIndex:i32<2>, TargetFrameIndex:i32<3>, t10<br>ISEL: Match complete!</div><div>...</div><div>ISEL: Starting selection on root node: t11: i32 = FrameIndex<2><br>ISEL: Starting pattern match<br>  Initial Opcode index to 0<br>  Match failed at index 0<br>LLVM ERROR: Cannot select: t11: i32 = FrameIndex<2></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Cheers.<br>
<br>
Tim.<br>
</blockquote></div></div>