<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 10/26/2017 12:52 PM, Matthias Braun
via llvm-dev wrote:<br>
</div>
<blockquote
cite="mid:C4F77BE8-BC6C-480E-9F7D-A9A7E1C9A1AD@braunis.de"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div class="">I like the idea, this is not the first time we try
to perform recoloring/renaming operations late. I agree with
Quentin though that we should have a way to mark def and use
operands! You can probably play more games and re-use the IsDead
bit on use operands.</div>
<div class=""><br class="">
</div>
<div>
<blockquote type="cite" class="">
<div class="">On Oct 26, 2017, at 5:54 AM, Nemanja Ivanovic
via llvm-dev <<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="">Forgive me if these questions are naive or
if I'm misunderstanding something. I'm certainly very
interested in seeing the MachineCopyPropagation patch
finally land and stick.<br class="">
<br class="">
</div>
1. Wouldn't function live-ins and reserved registers
have started life as physical registers already? For
example, wouldn't a live-in be a copy from a physical
register to a virtual one allowing the flag to be set
correctly on the def? A reserved register on the other
hand just seems like something we shouldn't touch,
doesn't it?<br class="">
</div>
2. I must admit that I don't really know how Aggressive
Anti Dependence Breaker works, but doesn't it already
rename registers? How does it know which ones are safe to
rename and which aren't?<br class="">
</div>
</div>
</blockquote>
<div>Heuristics which seem to work today but which at least I am
not very comfortable with.</div>
</div>
</blockquote>
<br>
+1<br>
<br>
It would be nice to replace this with a less fragile approach. We
already have number of instructions marked with
hasExtraSrcRegAllocReq and/or hasExtraDefRegAllocReq, and this seems
like a more-precise, dynamic, version of that.<br>
<br>
I don't recall this being mentioned, but I imagine we'll also, in
many cases, want to mark registers returned by the scavenger marked
as eligible for renaming.<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:C4F77BE8-BC6C-480E-9F7D-A9A7E1C9A1AD@braunis.de"
type="cite">
<div>
<div> I think it's mostly this part:</div>
<div><br class="">
</div>
<div>
<div> // If MI's defs have a special allocation requirement,
don't allow</div>
<div> // any def registers to be changed. Also assume all
registers</div>
<div> // defined in a call must not be changed (ABI).
Inline assembly may</div>
<div> // reference either system calls or the register
directly. Skip it until we</div>
<div> // can tell user specified registers from
compiler-specified.</div>
<div> if (MI.isCall() || MI.hasExtraDefRegAllocReq() ||
TII->isPredicated(MI) ||</div>
<div> MI.isInlineAsm()) {</div>
<div> DEBUG(if (State->GetGroup(Reg) != 0) dbgs()
<< "->g0(alloc-req)");</div>
<div> State->UnionGroups(Reg, 0);</div>
<div> }</div>
<div><br class="">
</div>
<div>- Matthias</div>
</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Wed, Oct 25, 2017 at 10:20 PM,
Quentin Colombet via llvm-dev <span dir="ltr" class=""><<a
moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org"
target="_blank" class="">llvm-dev@lists.llvm.org</a>></span>
wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi
Geoff,<br class="">
<br class="">
The principle sounds reasonable but it raises the
question of proper APIs to query that. E.g., when I am
looking at a use, how would we know that this is okay
to rename? In other words, what API do we provide for
such use cases.<br class="">
<br class="">
Also, what do we do with registers that don’t have
definition? For instance, a function live-ins
register, a reserved register, and so on.<br class="">
<br class="">
Cheers,<br class="">
-Quentin<br class="">
<div class="HOEnZb">
<div class="h5"><br class="">
> On Oct 25, 2017, at 10:27 AM, Geoff Berry
<<a moz-do-not-send="true"
href="mailto:gberry@codeaurora.org" class="">gberry@codeaurora.org</a>>
wrote:<br class="">
><br class="">
> Hi All,<br class="">
><br class="">
> Currently, changing register assignments of
definitions after register allocation is not safe
because there is no way to know which register
definitions were physical registers before RA
(e.g. to meet ABI or ISA constraints) and thus
should not be changed. I'd like to propose adding
a bit to MachineOperand (by overloading the
meaning of the IsKill bit for defs, so no extra
storage would be required), that tracks whether a
given register definition was a virtual register
before RA. I'll throw out 'IsRenameable' for a
potential name.<br class="">
><br class="">
> Register definitions created with virtual
registers would have this bit set. This bit
should be verifiable until after RA. Register
definitions created after RA (presumably with
physical registers) would not have this bit set.
I believe the only potential for this bit to be
set incorrectly (and not be caught be
verification) would be if a post-RA pass was
already renaming a register definition from a
previously virtual register to a previously
non-virtual register, which would arguably be a
bug already.<br class="">
><br class="">
> We have encountered several potential uses
for this bit. For example, the
MachineCopyPropagation changes I have been working
on to forward register COPYs would likely be
greatly simplified if this bit were available.
Other passes, like AArch64LoadStoreOptimizer,
which run post-RA so as not to overly-restrict the
register allocator, could be made to catch more
cases if renaming of load instructions could be
done safely.<br class="">
><br class="">
> --<br class="">
> Geoff Berry<br class="">
> Employee of Qualcomm Datacenter Technologies,
Inc.<br class="">
> Qualcomm Datacenter Technologies, Inc. as an
affiliate of Qualcomm Technologies, Inc. Qualcomm
Technologies, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project.<br
class="">
<br class="">
______________________________<wbr class="">_________________<br
class="">
LLVM Developers mailing list<br class="">
<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br
class="">
<a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr
class="">mailman/listinfo/llvm-dev</a><br
class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br
class="">
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>