[llvm-dev] Question about instruction selection (original) (raw)
Tim Northover via llvm-dev llvm-dev at lists.llvm.org
Sat Jan 19 04:09:49 PST 2019
- Previous message: [llvm-dev] Question about instruction selection
- Next message: [llvm-dev] Ideas and Prep for GSoC 2019
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
- Previous message: [llvm-dev] Question about instruction selection
- Next message: [llvm-dev] Ideas and Prep for GSoC 2019
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]