dumb question about CG ISel pattern matching

Project Infrastructure LLVM Dev List Archives
1

When I have a MOV instruction in my dot-td-file with an explicit pattern

Def MOV Format_RR < ,

[(set i32:$dst, i32:$src)]>;

then Instruction Selection goes haywire, why is that ?

(I have noticed that other targets get around this by defining their MOV

Instrs with an empty pattern, but that seems weird to me (and it’s

undocumented which also seems weird to me))

Unfortunately this is not an idle question, because my target has

separate Address and Data registers I need to add these NOP-ish defs:

Def MOVDA Format_RR < ,

[(set i32:$dst, (bitconvert p32:$src))]>;

Def MOVAD Format_RR < ,

[(set p32:$dst, (bitconvert i32:$src))]>;

which actually work just fine, but when I also add these

even more NOP-ish defs:

Def MOVDD Format_RR < ,

[(set i32:$dst, (bitconvert i32:$src))]>;

Def MOVAA Format_RR < ,

[(set p32:$dst, (bitconvert p32:$src))]>;

then I start seeing I-Select going haywire again, why is that ?

By “haywire” I mean –debug-only=isel shows really long lists

of “Match failed at index ###” ending in compilation failure,

which are otherwise really short and don’t fail.

–Peter Lawrence.

2

Move instructions in general should only be selected by your target’s implementation of TargetInstrInfo::copyPhysReg. This should get called when the register allocation logic determines it needs to change register classes or when it needs to move to another register in the same class.

For more complicated cases you can add an explicit pattern to emit a COPY_TO_REGCLASS pseudo instruction. You may need that since it looks like you’ve created a separate p32 type.