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

Sat Aug 22 09:38:48 PDT 2015

Ok, I suppose handling the COPY is easier considering the dangers of
possible later uses and instruction restrictions. We'll just have to write
a backend pass to clean up all the issues with redundant moves generated by
table-gen and isel limitations. Thanks for the help!

On Sat, Aug 22, 2015 at 12:10 PM, Ryan Taylor <ryta1203 at gmail.com> wrote:

> One last question regarding this please.
>
> Why aren't we simply changing the register class in AddRegisterOperand
> instead of building a new COPY? I admit I haven't thought this out but for
> my test cases so far this works just fine and reduces the number of ASM mov
> instructions that are being produced.
>
> For example, instead of BuildMI(..., TII->get(TargetOpcode::COPY),
> NewVReg).addReg(VReg), use something like MRI->setRegClass(VReg,
> MRI->getRegClass(NewVReg)) ?
>
> What is the reasoning behind adding the extra instruction instead of
> changing the reg class?
>
> On Wed, Aug 19, 2015 at 2:04 PM, Ryan Taylor <ryta1203 at gmail.com> wrote:
>
>> Yes, you're probably right about the ID. The odd part is that I have
>> other simpler instructions that use the same type of superset and it
>> always, so far, matches correctly (it doesn't just pick GPRRegs all the
>> time).
>>
>> Like I said, we can just 'fill in the gaps' with new MIs but that sure
>> seems like a brush off solution. The td files would be so much cleaner if
>> you could have a superset reg class that actually matched the correct reg
>> usage (which it sort of does in AddRegisterOperand when it adds the extra
>> COPY.... not sure why it does this instead of just checking the original MI
>> and seeing if the reg class needed is in the list and then just changing
>> the vreg reg class for the original MI, that seems like a better solution?)
>> It's like it's actually picking some reg class first and then trying to fix
>> it's error by adding MORE instructions instead of finding the right reg
>> class the first time.
>>
>> Thanks.
>>
>> On Wed, Aug 19, 2015 at 1:32 PM, Quentin Colombet <qcolombet at apple.com>
>> wrote:
>>
>>>
>>> On Aug 19, 2015, at 9:42 AM, Ryan Taylor <ryta1203 at gmail.com> wrote:
>>>
>>> It seems the problem arises from using multiple reg classes for one MI
>>> in the td file, I guess.
>>>
>>>
>>> Probably, that does not sound something used widely :).
>>>
>>>
>>> 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.
>>>
>>>
>>> My guess is it would take the register class that come first in the
>>> register class IDs (not the list on the instruction itself), but I am just
>>> guessing.
>>>
>>>
>>> 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/20150822/01101cf9/attachment.html>