<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Quentin,</p>
<p>thanks again for your time. We were now able to implement this
and it seems to be working as intended.</p>
<p>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.<br>
</p>
<p>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.</p>
<p>Thank you and best regards,</p>
<p>Dominik<br>
</p>
<div class="moz-cite-prefix">Am 14.03.20 um 00:17 schrieb Quentin
Colombet:<br>
</div>
<blockquote type="cite"
cite="mid:FB7F6A95-D9D8-462B-806C-F349CB347044@apple.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
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=""
moz-do-not-send="true">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=""
moz-do-not-send="true">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=""
moz-do-not-send="true">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="">
</blockquote>
<pre class="moz-signature" cols="72">--
----------------------------------------------------------------------
Dominik Montada Email: <a class="moz-txt-link-abbreviated" href="mailto:dominik.montada@hightec-rt.com">dominik.montada@hightec-rt.com</a>
HighTec EDV-Systeme GmbH Phone: +49 681 92613 19
Europaallee 19 Fax: +49-681-92613-26
D-66113 Saarbrücken WWW: <a class="moz-txt-link-freetext" href="http://www.hightec-rt.com">http://www.hightec-rt.com</a>
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.
--- </pre>
</body>
</html>