[llvm-dev] Correct modelling of instructions with types smaller than the register class
Amara Emerson via llvm-dev
llvm-dev at lists.llvm.org
Thu Mar 19 11:24:08 PDT 2020
Hi Dominik,
Sorry I’ve been very busy with some urgent things so haven’t had time to read this thread. I’ll try to get back to you this week or early next.
Cheers,
Amara
> On Mar 18, 2020, at 4:00 AM, Dominik Montada <dominik.montada at hightec-rt.com> wrote:
>
> Hi Quentin,
>
> thanks again for your time. We were now able to implement this and it seems to be working as intended.
>
> In the end with went with replacing the virtual registers with the physical one and checking for overlaps. We wanted to let the register allocator handle it initially but ended up having a couple more issues than we expected with that, so we now do this handling ourselves.
>
> It would still be very interesting to know why AArch64 isn't doing something similar and how exactly they are solving this issue, but for now I'm happy that we now have a working implementation for our target.
>
> Thank you and best regards,
>
> Dominik
>
> Am 14.03.20 um 00:17 schrieb Quentin Colombet:
>> Hi Dominik,
>>
>>> On Mar 12, 2020, at 9:46 AM, Dominik Montada <dominik.montada at hightec-rt.com <mailto:dominik.montada at hightec-rt.com>> wrote:
>>>
>>> Hi Quentin,
>>>
>>> thank you for the reply! I have a couple more questions that came up when I tried to implement this today. I hope you can help me out with this again!
>>>
>>> Am 09.03.20 um 23:31 schrieb Quentin Colombet:
>>>> I would expect that you could create a register class and register bank for the special register. That way you have something to map to when you do register bank select.
>>>> The register class could be "not allocatable” (see CCR in AArch64 for instance).
>>>> Note, that if that class is unallocable, you’ll have to manage manually any overlapping that could arise.
>>>> E.g.,
>>>> s32 ..., s1 carry1 = G_UADDO
>>>> s32 ..., s1 carry2 = G_UADDO
>>>> s32 extended_carry1 = zext s1 carry1 <— carry1 will be destroyed by the second G_UADDO, you’ll have to fix the schedule or copy the value manually.
>>>> s32 extended_carry2 = zext s1 carry2
>>>> icmp s32 extended_carry1, extended_carry2
>>> So before instruction selection we would need to check if there are any overlaps and if so try to fix them if possible or abort compilation if that is not possible?
>>
>> You could do it after (or during selection maybe), but yeah, you’ll need to fix that eventually. For now, I guess you could just abort if you run in that situation.
>>
>>>>
>>>> Then when you do instruction selection, just map the register to the physical register. (You may want to do the fix-ups I mentioned here.)
>>>
>>> What exactly do you mean by "map the register to the physical register"? Do you mean that I should just emit a COPY from/to this physical register and constrain the virtual register to the non-allocatable register class?
>>> Because this actually gives me an assertion that the register class must be allocatable. Or do you mean to use the physical register in the target instruction instead of the virtual one (i.e. drop the usage of the virtual register and replace it with the physical register)?
>>
>> The latter: replace the virtual register with the physical register directly. That way the only copies left would be to/from general purpose registers, if any. The problem with doing that is that you have to check for potential overlaps manually.
>>
>> Another option would be to go with the special register class we already talked about, make it allocatable, with just one register. That way if there are overlapping ones, regalloc will take care of them (probably with "ran out of register” if you don’t do anything.)
>>
>>> The target instruction uses the physical register implicitly by the way.
>>>
>>> I also tried to take a look at how AArch64 implements G_UADDO/G_UADDE but it doesn't seem to fully implement selection for those? Maybe I just didn't read the code properly...
>>
>> That could be right, it’s been a while since I looked at the code there.
>>
>>>
>>>>
>>>> I would expect that you could create a register class and register bank for the special register. That way you have something to map to when you do register bank select.
>>>>
>>> I looked at the CC regbank of AArch64, however I didn't see any mappings using it in RegBankInfo.
>>
>> I see that in AArch64RegisterBanks.td:
>> /// Conditional register: NZCV.
>> def CCRegBank : RegisterBank<"CC", [CCR]>;
>>
>> But that’s about it.
>>
>>> Is that something that AArch64 simply hasn't implemented or is there something going on that I'm not seeing. I mean, what is the point to have a register bank when it is not used during regbankselect?
>>
>> Good point. Again, it’s been a while I haven’t looked at AArch64, so I don’t really know the status here.
>> @Tim, @Amara?
>>
>>> I would at least expect that for example G_UADDO would use this register bank for the s1 carry out.
>>
>> That would have been my expectation as well.
>>
>>>>
>>>> Generally speaking, I think you would need a copy (or zext/sext) to move the value in general purpose land (like in my example with zext). If you don’t have such use, the copy wouldn’t be emitted and there is nothing to do.
>>>>
>>>> To be honest, I think the situation is complicated today because GISel lack the fix-up that I mentioned. I am actually surprised that didn’t come up as an issue yet (x86 is full of these flags). Going forward, I think it should just come with the framework: you assign a physreg selection time, GISel copies it around/reschedule appropriately to preserve the value. There’s a lot of wishful thinking here x).
>>>>
>>>> Cheers,
>>>> -Quentin
>>>>
>>> Best regards,
>>>
>>> Dominik
>>>
>>> --
>>> ----------------------------------------------------------------------
>>> Dominik Montada Email: dominik.montada at hightec-rt.com <mailto:dominik.montada at hightec-rt.com>
>>> HighTec EDV-Systeme GmbH Phone: +49 681 92613 19
>>> Europaallee 19 Fax: +49-681-92613-26
>>> D-66113 Saarbrücken WWW: http://www.hightec-rt.com <http://www.hightec-rt.com/>
>>>
>>> Managing Director: Vera Strothmann
>>> Register Court: Saarbrücken, HRB 10445, VAT ID: DE 138344222
>>>
>>> This e-mail may contain confidential and/or privileged information. If
>>> you are not the intended recipient please notify the sender immediately
>>> and destroy this e-mail. Any unauthorised copying, disclosure or
>>> distribution of the material in this e-mail is strictly forbidden.
>>> ---
>>>
>>
> --
> ----------------------------------------------------------------------
> Dominik Montada Email: dominik.montada at hightec-rt.com <mailto:dominik.montada at hightec-rt.com>
> HighTec EDV-Systeme GmbH Phone: +49 681 92613 19
> Europaallee 19 Fax: +49-681-92613-26
> D-66113 Saarbrücken WWW: http://www.hightec-rt.com <http://www.hightec-rt.com/>
>
> Managing Director: Vera Strothmann
> Register Court: Saarbrücken, HRB 10445, VAT ID: DE 138344222
>
> This e-mail may contain confidential and/or privileged information. If
> you are not the intended recipient please notify the sender immediately
> and destroy this e-mail. Any unauthorised copying, disclosure or
> distribution of the material in this e-mail is strictly forbidden.
> ---
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200319/183e3b71/attachment.html>
More information about the llvm-dev
mailing list