LEAQ instruction path


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.

%1 = alloca i32, align 4
%2 = alloca i32*, align 8
store i32 10, i32* %1, align 4
store i32* %1, i32** %2, align 8


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.

This is set up by the pattern for LEA64r here

def LEA64r : RI<0x8D, MRMSrcMem, (outs GR64:$dst), (ins lea64mem:$src),
“lea{q}\t{$src|$dst}, {$dst|$src}”,
[(set GR64:$dst, lea64addr:$src)], IIC_LEA>;

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.

def lea64addr : ComplexPattern<i64, 5, “selectLEAAddr”,
[add, sub, mul, X86mul_imm, shl, or, frameindex,
X86WrapperRIP], []>;

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

ISEL: Starting pattern match on root node: t2: i64 = FrameIndex<0>

Initial Opcode index to 130065
TypeSwitch[i64] from 130066 to 130107
MatchAddress: X86ISelAddressMode 0x7ffee68ae4f8
Base_Reg nul
Scale 1
IndexReg nul
Disp 0
GV nul CP nul
ES nul MCSym nul JT-1 Align0
Morphed node: t2: i64 = LEA64r TargetFrameIndex:i64<0>, TargetConstant:i8<1>, Register:i64 %noreg, TargetConstant:i32<0>, Register:i32 %noreg

I hope this helps.