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

[Ryan Taylor via llvm-dev]

Can someone please tell me where in the ISEL process is the heuristic for
assigning reg classes?

Thank you.


On Mon, Aug 17, 2015 at 7:00 PM, Ryan Taylor <ryta1203 at gmail.com> wrote:

>
> ---------- Forwarded message ----------
> From: Ryan Taylor <ryta1203 at gmail.com>
> Date: Mon, Aug 17, 2015 at 6:59 PM
> Subject: Re: [LLVMdev] TableGen Register Class not matching for MI in 3.6
> To: Quentin Colombet <qcolombet at apple.com>
> Cc: "llvmdev at cs.uiuc.edu" <llvmdev at cs.uiuc.edu>
>
>
> The isel logs are exactly the same, nothing changed, it's matching the
> same instructions just the reg classes are different.
>
> Where in the SelectionDAG is the code that adds an extra MI COPY? I'll
> have to set a breakpoint and debug backwards from there to see what's going
> on. It's only happening with the GPRRegs class, for example if I use
> another reg class instead along with the base regs than it matches the base
> reg just fine, it's like GPR is overriding any other reg class matching.
>
> Thanks.
>
> On Fri, Jul 31, 2015 at 1:21 PM, Quentin Colombet <qcolombet at apple.com>
> wrote:
>
>>
>> On Jul 31, 2015, at 10:14 AM, Ryan Taylor <ryta1203 at gmail.com> wrote:
>>
>> 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.
>>
>>
>> Then, I suggest you use -debug-only=isel to check what changed in your
>> selection instruction process. I do not see off-hand what could have caused.
>>
>> Sorry for not being more helpful here.
>>
>> Q.
>>
>>
>>
>> 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/20150819/ff990709/attachment.html>