llvm dev - Sep 2007 - [LLVMdev] Q about instruction pattern matching

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?

Thanks,
Andreas

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>

On 9/21/07, Christopher Lamb <christopher.lamb at gmail.com> wrote:
> 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.
Thanks, I guess that makes sense. I might as well go ahead and create
a general-purpose register class but then require that some operations
only target the data registers. For instance, multiplication is going
to require data registers while indirect addressing requires address
registers.

Could something like the Uses and Defs constraints apply to whole
register classes as well? For instance, I assume the register
allocated is going to guarantee that EAX:EDX is not allocated around
an x86 integer division, and that the inputs end up in the right
registers. If those constraints "ripple up" through the function,
couldn't that be augmented to solve this problem as well so that
arithmetic would automatically select the data registers?

Thanks,
// A