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

[Dominik Montada via llvm-dev]

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?
>
> 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 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...

>
> 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. 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? I would at least expect that for example G_UADDO would 
use this register bank for the s1 carry out.
>
> 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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5409 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200312/60c2d4ac/attachment-0001.bin>