[llvm-dev] Correct modelling of instructions with types smaller than the register class

Quentin Colombet via llvm-dev llvm-dev at lists.llvm.org
Fri Mar 13 16:17:37 PDT 2020

Hi Dominik,

> On Mar 12, 2020, at 9:46 AM, Dominik Montada <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
> 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
> 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/20200313/919ef3b6/attachment.html>

More information about the llvm-dev mailing list