<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 02/09/2017 06:18 PM, Mike Stump via
llvm-dev wrote:<br>
</div>
<blockquote
cite="mid:0982C246-53EC-4BF0-9757-643FFA69AB43@comcast.net"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div class="BodyFragment"><font size="2"><span
style="font-size:10pt;">
<div class="PlainText">Is there any reason why we can't
generate HWEncoding based decoders for registers for mc
disassemblers?<br>
</div>
</span></font></div>
</blockquote>
<br>
I suspect that, for many targets, this is possible. It is just that
no one has done the work to make this happen.<br>
<br>
So that we're on the same page, I believe you're talking about
getting rid of tables like this from
lib/Target/PowerPC/Disassembler/PPCDisassembler.cpp:<br>
<br>
// FIXME: These can be generated by TableGen from the existing
register<br>
// encoding values!<br>
<br>
static const unsigned CRRegs[] = {<br>
PPC::CR0, PPC::CR1, PPC::CR2, PPC::CR3,<br>
PPC::CR4, PPC::CR5, PPC::CR6, PPC::CR7<br>
};<br>
<br>
static const unsigned CRBITRegs[] = {<br>
PPC::CR0LT, PPC::CR0GT, PPC::CR0EQ, PPC::CR0UN,<br>
PPC::CR1LT, PPC::CR1GT, PPC::CR1EQ, PPC::CR1UN,<br>
PPC::CR2LT, PPC::CR2GT, PPC::CR2EQ, PPC::CR2UN,<br>
PPC::CR3LT, PPC::CR3GT, PPC::CR3EQ, PPC::CR3UN,<br>
PPC::CR4LT, PPC::CR4GT, PPC::CR4EQ, PPC::CR4UN,<br>
PPC::CR5LT, PPC::CR5GT, PPC::CR5EQ, PPC::CR5UN,<br>
PPC::CR6LT, PPC::CR6GT, PPC::CR6EQ, PPC::CR6UN,<br>
PPC::CR7LT, PPC::CR7GT, PPC::CR7EQ, PPC::CR7UN<br>
};<br>
<br>
...<br>
<br>
<blockquote
cite="mid:0982C246-53EC-4BF0-9757-643FFA69AB43@comcast.net"
type="cite">
<div class="BodyFragment"><font size="2"><span
style="font-size:10pt;">
<div class="PlainText">
<br>
This is a concept patch to explore wether it'd work, and
for my target, it does the right thing. I have one case
where I have to shift a field over 2 bits, but I handle
that in the glue. If I had a HWEncoding encoding on a per
register class basis, I could have made it work without
the extra shift. I have 8 register classes across 5
register files, so the code can handle at least a little
complexity.<br>
<br>
I work at silicon design time, and we update registers
like people wash their hair. Having the tool auto
generate most all that I need saves me the time and
complexity to keep these up-to-date as we change the
design. I suspect others might find register decoding
useful. Some ports are so trivial that they can use
register class ordering to decode. Another possibility is
to reject the patch as a bad idea, and deprecate
HWEncoding entirely and recommend people write their
register class in encoding order,</div>
</span></font></div>
</blockquote>
<br>
I'm against using implicit ordered in the TableGen file to generate
the hardware encoding numbers. This would lead to unnecessary
gymnastics assuming it were usable at all.<br>
<br>
<blockquote
cite="mid:0982C246-53EC-4BF0-9757-643FFA69AB43@comcast.net"
type="cite">
<div class="BodyFragment"><font size="2"><span
style="font-size:10pt;">
<div class="PlainText"> and use other means to change the
allocation order.</div>
</span></font></div>
</blockquote>
<br>
Many targets adjust the allocation order anyway for a variety of
reasons, so I'd tend to view this as an orthogonal concern. <br>
<br>
<blockquote
cite="mid:0982C246-53EC-4BF0-9757-643FFA69AB43@comcast.net"
type="cite">
<div class="BodyFragment"><font size="2"><span
style="font-size:10pt;">
<div class="PlainText"> That might be a better way to do
this. I started out with HWEncoding based post, then
discovered there was no decoder; maybe that was just
wrong?<br>
<br>
I'd be interested in hearing what others might recommend
(ditch HWEncoding?), and if people find the direction the
patch does, in collaborating with someone if they want to
finish off the patch. Open questions, always generate
tables, even if a target doesn't use HWEncoding? Generate
by default, or hide all the new routines unless someone
asks for them? Move the code into the Disassembler
generator out of the RegisterInfo generator?<br>
<br>
Thoughts?<br>
</div>
</span></font></div>
</blockquote>
<br>
Moving the code to the disassembler generator makes sense, although
at least on PowerPC, we have equivalent tables in the AsmParser and
we should eliminate them in both places. I recommend only generating
(or including) the tables upon request. One way to this is to add a
flag variable to InstrInfo (declared in
include/llvm/Target/Target.td) like
decodePositionallyEncodedOperands. Another way is to add a flag to
each register class indicating whether or not a table should be
generated for that class. Another way is to always generate the
tables for each register class for which the HWEncoding uniquely
identifies each register, and surround those tables with some ifdef
(like we do with GET_INSTRMAP_INFO).<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:0982C246-53EC-4BF0-9757-643FFA69AB43@comcast.net"
type="cite">
<div class="BodyFragment"><font size="2"><span
style="font-size:10pt;">
<div class="PlainText">
<br>
</div>
</span></font></div>
<div class="BodyFragment"><font size="2"><span
style="font-size:10pt;">
<div class="PlainText">_______________________________________________<br>
LLVM Developers mailing list<br>
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div>
</span></font></div>
</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>