llvm dev - Jun 2016 - dumb question about CG ISel pattern matching

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160622/49bd8673/attachment.html>

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.

On Tue, Jun 21, 2016 at 7:09 PM, Lawrence, Peter via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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.
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>

-- 
~Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160621/2af596fb/attachment.html>