llvm dev - Jan 2019 - Question about instruction selection

Hi,
I'm new to LLVM and trying to understand instruction selection. I compiled
this llvm IR using llc with the '-debug' flag

define i32 @func() #0 {
  %a = alloca i32, align 4
  %1 = load i32, i32* %a, align 4
  ret i32 %1
}

The resulting assembly is

ADS -8
LDW $r0, $sp, 0                # 4-byte Folded Reload
MOVR $r0, $r0
LDW $r4, $r0, 0
STSP $r0, 0
ADS 8
JLR

I'm trying to understand why r0 is being moved to itself. The debug output
indicates this:

ISEL: Starting selection on root node: t1: i32 = FrameIndex<0>
ISEL: Starting pattern match
  Morphed node: t1: i32 = MOVR t1
ISEL: Match complete!

In InstrInfo.td, MOVR has this dag pattern: [(set CPURegs:$ra, CPURegs:$rb)]. I
don't understand how node t1's pattern matched MOVR's pattern.

Can someone point me to a location in the code where FrameIndex's pattern is
defined?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190119/8f167ca3/attachment.html>

On Sat, 19 Jan 2019 at 02:03, Josh Sharp via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> In InstrInfo.td, MOVR has this dag pattern: [(set CPURegs:$ra,
CPURegs:$rb)]. I don't understand how node t1's pattern matched
MOVR's pattern.
A plain register class will match any node of the correct type, in
this case trivially. You'd expect that not to actually consume
anything and go into infinite recursion, but maybe the mere fact that
it has matched means it won't be considered again. I can't quite
picture what the DAG looks like after this match, but I suspect it's
actually cyclic and certainly not good.

You never really want to write patterns for plain moves like that;
MOVRs will get inserted later by calling the copyPhysReg function when
needed.
> Can someone point me to a location in the code where FrameIndex's
pattern is defined?
A node you can use in more elaborate patterns is "frameindex" in
TargetSelectionDAG.td.cd, though that one is usually handled in C++
code rather than with TableGen patterns.

The idea is that you convert the FrameIndex into some kind of add
instruction that can operate on SP with a TargetFrameIndex as an
operand and usually dummy zeroes for the offset. That instruction is
usually a bit odd because what would normally be the LHS addition
register is this TargetFrameIndex node instead, and gets lowered into
actual stack arithmetic later. See for example
AArch64ISelDAGToDAG.cpp, around line 2888.

Cheers.

Tim.