llvm dev - Jul 2015 - [LLVMdev] TableGen Register Class not matching for MI in 3.6

In LLVM 3.6,

 We have an instruction that uses a register class that is defined of
several different reg classes. In 3.4 this works fine but in 3.6 this is
broken.

For example, I have a mov instruction. mov can be executed between
different register types (ie gpr, index, base, etc..)

In 3.4, we would get something like this:

mov @a, %b1 // moving this immediate to a base register, which is what we
want

In 3.6, we now get this:

mov @a, %r0  // r0 = gpr
mov %r0, %b1 // b1 = base reg

The register class looks like this:

def ARegs : RegisterClass<"us", [i16], i16, (add GPRRegs,
IndexRegs,
BaseRegs)>;

I have absolutely no idea why this is not matching any longer?

The fix here is to define an MI with explicit single register class (ie it
only allows PTRRegs as the destination).

This must be an issue with something else and not the tablegen but if that
was the case I'm not sure. Anyway help would be great, what should I be
looking at here?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150730/ccd61db9/attachment.html>

Hi Ryan,

Could you check where those moves come from?

In particular, is this the product of the instruction selection process?

You use -print-machineinstrs to see when it is inserted.

Thanks,
-Quentin
> On Jul 30, 2015, at 2:02 PM, Ryan Taylor <ryta1203 at gmail.com>
wrote:
> 
> In LLVM 3.6,
> 
>  We have an instruction that uses a register class that is defined of
several different reg classes. In 3.4 this works fine but in 3.6 this is broken.
> 
> For example, I have a mov instruction. mov can be executed between
different register types (ie gpr, index, base, etc..)
> 
> In 3.4, we would get something like this:
> 
> mov @a, %b1 // moving this immediate to a base register, which is what we
want
> 
> In 3.6, we now get this:
> 
> mov @a, %r0  // r0 = gpr
> mov %r0, %b1 // b1 = base reg
> 
> The register class looks like this:
> 
> def ARegs : RegisterClass<"us", [i16], i16, (add GPRRegs,
IndexRegs, BaseRegs)>;
> 
> I have absolutely no idea why this is not matching any longer?
> 
> The fix here is to define an MI with explicit single register class (ie it
only allows PTRRegs as the destination).
> 
> This must be an issue with something else and not the tablegen but if that
was the case I'm not sure. Anyway help would be great, what should I be
looking at here?
> 
> Thanks.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Quentin,

 It's in the instruction selection, sorry I forgot to mention that. The
Vreg class is GPR and an extra COPY is generated to copy from the GPR to
the Base Reg, even though my 'mov' instruction has Base in the Register
class list.


On Fri, Jul 31, 2015 at 12:50 PM, Quentin Colombet <qcolombet at
apple.com>
wrote:
> Hi Ryan,
>
> Could you check where those moves come from?
>
> In particular, is this the product of the instruction selection process?
>
> You use -print-machineinstrs to see when it is inserted.
>
> Thanks,
> -Quentin
>
> > On Jul 30, 2015, at 2:02 PM, Ryan Taylor <ryta1203 at gmail.com>
wrote:
> >
> > In LLVM 3.6,
> >
> >  We have an instruction that uses a register class that is defined of
> several different reg classes. In 3.4 this works fine but in 3.6 this is
> broken.
> >
> > For example, I have a mov instruction. mov can be executed between
> different register types (ie gpr, index, base, etc..)
> >
> > In 3.4, we would get something like this:
> >
> > mov @a, %b1 // moving this immediate to a base register, which is what
> we want
> >
> > In 3.6, we now get this:
> >
> > mov @a, %r0  // r0 = gpr
> > mov %r0, %b1 // b1 = base reg
> >
> > The register class looks like this:
> >
> > def ARegs : RegisterClass<"us", [i16], i16, (add GPRRegs,
IndexRegs,
> BaseRegs)>;
> >
> > I have absolutely no idea why this is not matching any longer?
> >
> > The fix here is to define an MI with explicit single register class
(ie
> it only allows PTRRegs as the destination).
> >
> > This must be an issue with something else and not the tablegen but if
> that was the case I'm not sure. Anyway help would be great, what should
I
> be looking at here?
> >
> > Thanks.
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150731/4cf51bee/attachment.html>