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

Essentially it doesn't appear that the reg class assignment is based on
uses and is instead inserting an extra COPY for this. Is this accurate? If
so, why?

In this above example, I'm getting an extra "mov %r0, $b1" (this
is an
MI::COPY) even though "mov @a, %b1" (this is an MI::MOV) is entirely
acceptable since both GPRRegs and BaseRegs are in the reg class list..

If the heuristic is simply picking the first available reg class or the reg
class with the most available, for example, instead of picking the reg
class based on uses, I will have to change this heuristic to reduce code
bloat, or we'll have to add backend passes to reduce the code bloat.

Thanks.

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/fce8c692/attachment.html>

Hi Ryan,
> On Aug 19, 2015, at 6:35 AM, Ryan Taylor via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Essentially it doesn't appear that the reg class assignment is based on
uses and is instead inserting an extra COPY for this. Is this accurate? If so,
why?
We match the instructions bottom-up and I believe that copy are automatically
inserted when the register classes do not match.
That seems strange to me that the isel logs are exactly the same but still you
are seeing a different result of instruction selection.
> 
> In this above example, I'm getting an extra "mov %r0, $b1"
(this is an MI::COPY) even though "mov @a, %b1" (this is an MI::MOV)
is entirely acceptable since both GPRRegs and BaseRegs are in the reg class
list..
> 
> If the heuristic is simply picking the first available reg class or the reg
class with the most available, for example, instead of picking the reg class
based on uses, I will have to change this heuristic to reduce code bloat, or
we'll have to add backend passes to reduce the code bloat.
I think the current approach is rather simple and we just match the type for the
first available reg class (assuming your selection dag patterns are not choosing
something different). There are not per say passes to reduce this "code
bloat” since we never encounter this problem in practice. The peephole optimizer
has some logic to avoid this move and CodeGenPrepare also does a few
transformation to avoid some of that.

Anyhow, I’d say debug the isel process (probably the InstrEmitter part) to see
where the problem arise.

Cheers,
-Quentin
> 
> Thanks.
> 
> On Mon, Aug 17, 2015 at 7:00 PM, Ryan Taylor <ryta1203 at gmail.com
<mailto:ryta1203 at gmail.com>> wrote:
> 
> ---------- Forwarded message ----------
> From: Ryan Taylor <ryta1203 at gmail.com <mailto: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 <mailto:qcolombet at
apple.com>>
> Cc: "llvmdev at cs.uiuc.edu <mailto:llvmdev at
cs.uiuc.edu>" <llvmdev at cs.uiuc.edu <mailto: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 <mailto:qcolombet at apple.com>> wrote:
> 
>> On Jul 31, 2015, at 10:14 AM, Ryan Taylor <ryta1203 at gmail.com
<mailto: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 <mailto: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
<mailto: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 <mailto:LLVMdev at cs.uiuc.edu>      
http://llvm.cs.uiuc.edu
<https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.cs.uiuc.edu_&d=BQMFaQ&c=eEvniauFctOgLOKGJOplqw&r=Kar_gr4lUTX9iRgFLHyIPCR7VD3VlB3-02h_Q5v9oWk&m=7VQTHNyB_IcF4I86741RzVduPmdgCRL_mHUfuUmnL0Y&s=fK8KXlXNFjX9EyldRbiY4GwaxZBFjvTYEXwRJuFLJvg&e=>
>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.cs.uiuc.edu_mailman_listinfo_llvmdev&d=BQMFaQ&c=eEvniauFctOgLOKGJOplqw&r=Kar_gr4lUTX9iRgFLHyIPCR7VD3VlB3-02h_Q5v9oWk&m=7VQTHNyB_IcF4I86741RzVduPmdgCRL_mHUfuUmnL0Y&s=TAPJBdWJfY-53g2FEN-kOKTo2nDJxcpEGNpqpgcrN9U&e=>
>> 
>> 
> 
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=Kar_gr4lUTX9iRgFLHyIPCR7VD3VlB3-02h_Q5v9oWk&m=7VQTHNyB_IcF4I86741RzVduPmdgCRL_mHUfuUmnL0Y&s=N0TOaZZSrDVRpbh_uMG5DV5ZZ2_KVMcBWtK9vGIaByY&e=
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150819/f60ce77a/attachment.html>

It seems the problem arises from using multiple reg classes for one MI in
the td file, I guess. I'm not sure it takes first available, if I swap the
reg classes in the list it does not change and if I replace the GPR reg
class with something different than it picks the base reg class fine,
potentially it is using the reg class with most available? idk.

I just need to create MIs for every possible case I guess.
Thanks for the help! :)

On Wed, Aug 19, 2015 at 12:04 PM, Quentin Colombet <qcolombet at
apple.com>
wrote:
> Hi Ryan,
>
> On Aug 19, 2015, at 6:35 AM, Ryan Taylor via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Essentially it doesn't appear that the reg class assignment is based on
> uses and is instead inserting an extra COPY for this. Is this accurate? If
> so, why?
>
>
> We match the instructions bottom-up and I believe that copy are
> automatically inserted when the register classes do not match.
> That seems strange to me that the isel logs are exactly the same but still
> you are seeing a different result of instruction selection.
>
>
> In this above example, I'm getting an extra "mov %r0, $b1"
(this is an
> MI::COPY) even though "mov @a, %b1" (this is an MI::MOV) is
entirely
> acceptable since both GPRRegs and BaseRegs are in the reg class list..
>
> If the heuristic is simply picking the first available reg class or the
> reg class with the most available, for example, instead of picking the reg
> class based on uses, I will have to change this heuristic to reduce code
> bloat, or we'll have to add backend passes to reduce the code bloat.
>
>
> I think the current approach is rather simple and we just match the type
> for the first available reg class (assuming your selection dag patterns are
> not choosing something different). There are not per say passes to reduce
> this "code bloat” since we never encounter this problem in practice.
The
> peephole optimizer has some logic to avoid this move and CodeGenPrepare
> also does a few transformation to avoid some of that.
>
> Anyhow, I’d say debug the isel process (probably the InstrEmitter part) to
> see where the problem arise.
>
> Cheers,
> -Quentin
>
>
> Thanks.
>
> 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
>>>>
<https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.cs.uiuc.edu_&d=BQMFaQ&c=eEvniauFctOgLOKGJOplqw&r=Kar_gr4lUTX9iRgFLHyIPCR7VD3VlB3-02h_Q5v9oWk&m=7VQTHNyB_IcF4I86741RzVduPmdgCRL_mHUfuUmnL0Y&s=fK8KXlXNFjX9EyldRbiY4GwaxZBFjvTYEXwRJuFLJvg&e=>
>>>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>
<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.cs.uiuc.edu_mailman_listinfo_llvmdev&d=BQMFaQ&c=eEvniauFctOgLOKGJOplqw&r=Kar_gr4lUTX9iRgFLHyIPCR7VD3VlB3-02h_Q5v9oWk&m=7VQTHNyB_IcF4I86741RzVduPmdgCRL_mHUfuUmnL0Y&s=TAPJBdWJfY-53g2FEN-kOKTo2nDJxcpEGNpqpgcrN9U&e=>
>>>>
>>>>
>>>
>>>
>>
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
>
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=Kar_gr4lUTX9iRgFLHyIPCR7VD3VlB3-02h_Q5v9oWk&m=7VQTHNyB_IcF4I86741RzVduPmdgCRL_mHUfuUmnL0Y&s=N0TOaZZSrDVRpbh_uMG5DV5ZZ2_KVMcBWtK9vGIaByY&e>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150819/4d0ce012/attachment-0001.html>