<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Dominik,<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 12, 2020, at 9:46 AM, Dominik Montada <<a href="mailto:dominik.montada@hightec-rt.com" class="">dominik.montada@hightec-rt.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi Quentin,<br class=""><br class="">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!<br class=""><br class="">Am 09.03.20 um 23:31 schrieb Quentin Colombet:<br class=""><blockquote type="cite" class="">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.<br class="">The register class could be "not allocatable” (see CCR in AArch64 for instance).<br class="">Note, that if that class is unallocable, you’ll have to manage manually any overlapping that could arise.<br class="">E.g.,<br class="">s32 ..., s1 carry1 = G_UADDO<br class="">s32 ..., s1 carry2 = G_UADDO<br class="">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.<br class="">s32 extended_carry2 = zext s1 carry2<br class="">icmp s32 extended_carry1, extended_carry2<br class=""></blockquote>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?<br class=""></div></div></blockquote><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class=""><br class="">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.)<br class=""></blockquote><br class="">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?</div></div></blockquote><blockquote type="cite" class=""><div class=""><div 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)?</div></div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><div>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.)</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">The target instruction uses the physical register implicitly by the way.<br class=""><br class="">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...<br class=""></div></div></blockquote><div><br class=""></div><div>That could be right, it’s been a while since I looked at the code there.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><br class="">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.<br class=""><br class=""></blockquote>I looked at the CC regbank of AArch64, however I didn't see any mappings using it in RegBankInfo.</div></div></blockquote><div><br class=""></div><div>I see that in <span style="font-family: Menlo; font-size: 11px;" class="">AArch64RegisterBanks.td</span>:</div><div><div style="margin: 0px; font-stretch: normal; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">/// Conditional register: NZCV.</span></div><div style="margin: 0px; font-stretch: normal; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">def CCRegBank : RegisterBank<"CC", [CCR]>;</span></div></div><div><br class=""></div><div>But that’s about it.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""> 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?</div></div></blockquote><div><br class=""></div><div>Good point. Again, it’s been a while I haven’t looked at AArch64, so I don’t really know the status here.</div><div>@Tim, @Amara?</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""> I would at least expect that for example G_UADDO would use this register bank for the s1 carry out.<br class=""></div></div></blockquote><div><br class=""></div><div>That would have been my expectation as well.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class=""><br class="">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.<br class=""><br class="">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).<br class=""><br class="">Cheers,<br class="">-Quentin<br class=""><br class=""></blockquote>Best regards,<br class=""><br class="">Dominik<br class=""><br class="">-- <br class="">----------------------------------------------------------------------<br class="">Dominik Montada <a href="mailto:dominik.montada@hightec-rt.com" class="">Email: dominik.montada@hightec-rt.com</a><br class="">HighTec EDV-Systeme GmbH Phone: +49 681 92613 19<br class="">Europaallee 19 Fax: +49-681-92613-26<br class="">D-66113 Saarbrücken WWW: <a href="http://www.hightec-rt.com" class="">http://www.hightec-rt.com</a><br class=""><br class="">Managing Director: Vera Strothmann<br class="">Register Court: Saarbrücken, HRB 10445, VAT ID: DE 138344222<br class=""><br class="">This e-mail may contain confidential and/or privileged information. If<br class="">you are not the intended recipient please notify the sender immediately<br class="">and destroy this e-mail. Any unauthorised copying, disclosure or<br class="">distribution of the material in this e-mail is strictly forbidden.<br class="">---<br class=""><br class=""></div></div></blockquote></div><br class=""></body></html>