<div dir="ltr">leaq is referred to has LEA64r in the X86 instruction td files. Isel uses X86DAGToDAGISel::selectLEAAddr to pattern match address calculations for lea in the DAG.<div><br></div><div>This is set up by the pattern for LEA64r here</div><div><br></div><div><div>def LEA64r : RI<0x8D, MRMSrcMem, (outs GR64:$dst), (ins lea64mem:$src),</div><div> "lea{q}\t{$src|$dst}, {$dst|$src}",</div><div> [(set GR64:$dst, lea64addr:$src)], IIC_LEA>;</div></div><div><br></div><div>lea64addr is defined as a complex pattern that should call selectLEAAddr to check for a match. I believe the list of things in the square brackets indicate the nodes that could possibly the root of an address calculation that an lea can encode.</div><div><br></div><div><div>def lea64addr : ComplexPattern<i64, 5, "selectLEAAddr",</div><div> [add, sub, mul, X86mul_imm, shl, or, frameindex,</div><div> X86WrapperRIP], []>;</div></div><div><br></div><div><br></div><div>For the case you gave I ran it through the backend on trunk. Here's where it selects the LEA64r instruction. The root nodes in this case is a FrameIndex</div><div><br></div><div><div>ISEL: Starting pattern match on root node: t2: i64 = FrameIndex<0></div><div><br></div><div> Initial Opcode index to 130065</div><div> TypeSwitch[i64] from 130066 to 130107</div><div>MatchAddress: X86ISelAddressMode 0x7ffee68ae4f8</div><div>Base_Reg nul</div><div> Scale 1</div><div>IndexReg nul</div><div> Disp 0</div><div>GV nul CP nul</div><div>ES nul MCSym nul JT-1 Align0</div><div> Morphed node: t2: i64 = LEA64r TargetFrameIndex:i64<0>, TargetConstant:i8<1>, Register:i64 %noreg, TargetConstant:i32<0>, Register:i32 %noreg</div></div><div><br></div><div><br></div><div>I hope this helps. </div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature">~Craig</div></div>
<br><div class="gmail_quote">On Wed, Jan 17, 2018 at 6:30 PM, Barbora Murinová via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I've been trying to teach LLVM that pointers are 128-bit long, which segfaults with some seemingly unrelated stacktrace when I try to take an address of a variable. Since stack saving and loading seems to work fine, I dare to assume the instruction causing problems there is leaq. Now I've done a search for leaq of the entire LLVM codebase with no success and I'd like to know which DAG nodes and eventually instructions does the last store in the following piece of code get translated to before it gets emitted.<br><br><div> %1 = alloca i32, align 4</div><div> %2 = alloca i32*, align 8</div><div> store i32 10, i32* %1, align 4</div><div> store i32* %1, i32** %2, align 8</div><div><br></div><div>Thanks,</div><div>Barbora</div><span class="HOEnZb"><font color="#888888"><div><br></div><div><br></div><div><br></div>-- <br><div class="m_-37496965678675723gmail_signature"><div dir="ltr"><div><font size="1" color="#999999">----------------</font></div><div><font size="1" color="#999999">Barbora Murinová</font></div><div><font size="1" color="#999999">The University of Edinburgh</font></div><div><font size="1" color="#999999">SK: <a href="tel:+421%20905%20718%20390" value="+421905718390" target="_blank">+421905718390</a><br>UK: <a href="tel:+44%207477%20833795" value="+447477833795" target="_blank">+447477833795</a></font></div></div></div>
</font></span></div></div>
<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>