[LLVMdev] Q about instruction pattern matching

[Christopher Lamb]

On Sep 21, 2007, at 2:04 AM, Andreas Fredriksson wrote:

> Hi,
> I'm trying to describe the patterns for the m68k instructions ADD and
> ADDA when used with a data register operand for the source. Basically,
> ADD operates on anything but address registers and immediates, and
> ADDA works on address registers only so I'm going to need both
> instructions in my instruction set.
>
> These are the two problematic definitions; by themselves they produce
> the intented effect. AR is the address register class, DR32 is the
> data register class (no overlap):
>
> // 32-bit add DR->DR
> def ADD_32_dx_dx : I<(outs DR32:$dst), (ins DR32:$src1, DR32:$src2),
> "add.l $src2, $dst", [(set DR32:$dst, (add DR32:$src2, DR32:$src1))]>;
>
> // 32-bit add DR->AR
> def ADDA_32_dx : I<(outs AR:$dst), (ins AR:$src1, DR32:$src2), "adda.l
> $src2, $dst", [(set AR:$dst, (add AR:$src1, DR32:$src2))]>;
>
> Tablegen tells me that "Pattern '(add:i32 DR32:i32:$src2,
> DR32:i32:$src1)' is impossible to select", but I can't figure out why.
> Are register classes not taken into account in the pattern matching or
> am I doing something else wrong?

ISel patterns are matched against DAGs before register allocation. So  
you are correct that ISel patterns can't take into account register  
classes. The register classes in the patterns are a selection  
constraint for the register allocator if that instruction is chosen,  
not a constraint on choosing that pattern.

Here's a possible way to proceed for now:
Define ADDA_32_dx without a pattern. Then in C++ pattern code for  
matching address operands select add operations on addresses to  
ADDA_32_dx. This way you know that the add your selecting is going to  
be used as an address and you can safely tell the register allocator  
to put the value in an address register.

Unfortunately dealing with heterogeneous register files like this is  
kind of annoying.
--
Christopher Lamb



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