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