<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<p>Hi Gabriel,</p>
<p>I'm working on a downstream target which uses GlobalISel and we
have many patterns with instructions that also define a system
register as a side-effect and use them without any problem. Since
CCReg is not an actual output of the instruction, but an implicit
definition, GlobalISel should have no trouble with it, so I'm
guessing your problem lies somewhere. Have you tried running the
tablegen command manually and looked at the output there?</p>
<p>The command is <tt>llvm-tblgen -gen-global-isel <couple of -I
flags> <your_target>.td --write-if-changed
--warn-on-skipped-patterns</tt><br>
</p>
<p>I can't tell you exactly what -I flags you'll need but if you run
ninja in verbose mode or look at the ninja build log, you should
be able to see what is being used.</p>
<p>Word of caution however: sometimes TableGen gives you a very
clear error message indicating what is wrong, sometimes it gives
you a very cryptic error message. And sometimes it doesn't even
give you that and behave as if everything is a-ok while it still
hasn't included your pattern. I have lost countless hours trying
to debug TableGen patterns with GlobalISel and there's still a lot
of stuff that GlobalISel unfortunately does not support yet in
TableGen. So be prepared to write some C++ code for the
unsupported cases for the moment.<br>
</p>
<p>Cheers,</p>
<p>Dominik<br>
</p>
<div class="moz-cite-prefix">Am 04.06.20 um 14:34 schrieb Gabriel
Hjort Åkerlund via llvm-dev:<br>
</div>
<blockquote type="cite"
cite="mid:AM6PR07MB551148591B80EED46A8A86ABBA890@AM6PR07MB5511.eurprd07.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">Hi,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US">I am in the process of
porting our target to GlobalISel, and have encountered a
problem. Nearly all instructions in our instruction set make
modifications to a CC register, and hence are defined as
follows:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier
New"" lang="EN-US">let ..., Defs = [CCReg] in<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier
New"" lang="EN-US">def shfts_a32_imm7:
Instruction<(outs OurRC:$dst), ...>;</span><span
lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-line-height-alt:3.0pt"><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="mso-line-height-alt:3.0pt"><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV"
lang="EN-US">What’s more, many of these instructions have
patterns where the instruction itself appears inside a
nested tree, e.g.:<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-line-height-alt:3.0pt"><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="mso-line-height-alt:3.0pt"><span
style="font-size:10.0pt;font-family:"Courier
New";color:#181818;mso-fareast-language:SV"
lang="EN-US">def Pat<(source pattern ...),<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-line-height-alt:3.0pt"><span
style="font-size:10.0pt;font-family:"Courier
New";color:#181818;mso-fareast-language:SV"
lang="EN-US"> (sext_a32 (INSERT_SUBREG (...),
(shfts_a32_imm7 OurRC:$src, Imm7:$imm), ...>;<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-line-height-alt:3.0pt"><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="mso-line-height-alt:3.0pt"><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV"
lang="EN-US">Now to the problem: When TableGen processes the
instruction above, it includes the
</span><span style="font-size:10.0pt;font-family:"Courier
New";color:#181818;mso-fareast-language:SV"
lang="EN-US">CCReg</span><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV"
lang="EN-US"> in the
</span><span style="font-size:10.0pt;font-family:"Courier
New";color:#181818;mso-fareast-language:SV"
lang="EN-US">Defs</span><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV"
lang="EN-US"> field along with the registers appearing in </span><span
style="font-size:10.0pt;font-family:"Courier
New";color:#181818;mso-fareast-language:SV"
lang="EN-US">outs</span><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV"
lang="EN-US">, thereby indicating that shfts_a32_imm7
produces two results. Currently, the GlobalISel-backend in
TableGen requires that nested instructions appearing in the
output pattern produce exactly one result. Consequently,
TableGen rejects many of our patterns. But in reality, the
instruction really only produces a single result and
therefore this pattern should be allowed.<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-line-height-alt:3.0pt"><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="mso-line-height-alt:3.0pt"><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV"
lang="EN-US">So I wonder, how should registers appear in
</span><span style="font-size:10.0pt;font-family:"Courier
New";color:#181818;mso-fareast-language:SV"
lang="EN-US">Defs</span><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV"
lang="EN-US"> be treated? Are they equal to those appearing
in </span><span
style="font-size:10.0pt;font-family:"Courier
New";color:#181818;mso-fareast-language:SV"
lang="EN-US">outs</span><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV"
lang="EN-US">, and therefore interchangeable, or is it valid
to disambiguate between them and therefore modify TableGen
to only consider
</span><span style="font-size:10.0pt;font-family:"Courier
New";color:#181818;mso-fareast-language:SV"
lang="EN-US">outs
</span><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV"
lang="EN-US">as the result of interest when processing the
patterns?<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-line-height-alt:3.0pt"><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="mso-line-height-alt:3.0pt"><b><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV">Gabriel
Hjort Åkerlund</span></b><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-line-height-alt:3.0pt"><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#181818;mso-fareast-language:SV"><o:p> </o:p></span></p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-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="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</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>