<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<p>Hi Gabriel,</p>
<p>Your comment made me take a look at our instruction definitions
and patterns in a little bit more detail. And while we do use
nested patterns with INSERT_SUBREG, apparently none of those
patterns use instructions with implicit-defs. Sorry for misleading
you there by a wrong assumption on my part.</p>
<p>However, I still find it strange that TableGen should reject such
a pattern. I'm really not sure if this is simply an overlooked
use-case or if there is some real reasoning behind this logic. If
it were an actual output register I could understand it, but since
this is an implicit one it should not impact the pattern in my
opinion.</p>
<p>Sorry for not being able to help out with the actual problem
after all!</p>
<p>Cheers,</p>
<p>Dominik<br>
</p>
<div class="moz-cite-prefix">Am 04.06.20 um 15:06 schrieb Gabriel
Hjort Åkerlund:<br>
</div>
<blockquote type="cite"
cite="mid:AM6PR07MB5511002410C945757CECC968BA890@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;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:"Ericsson Hilda";
panose-1:0 0 5 0 0 0 0 0 0 0;}
/* 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;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New",serif;
mso-fareast-language:SV;}
tt
{mso-style-priority:99;
font-family:"Courier New",serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:SV;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
mso-fareast-language:EN-US;}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Ericsson Hilda";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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"><span style="font-family:"Ericsson
Hilda"">Hi Dominik,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda"">Thanks for your reply.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda"" lang="EN-US">In my case, the </span><span
style="font-family:"Courier New",serif"
lang="EN-US">Defs</span><span
style="font-family:"Ericsson Hilda"" lang="EN-US">
is the cause of the problem. Or rather, it is part of the
problem, because when I remove it from the instruction
TableGen gives me a different error message which concerns a
part which is deeper into the pattern tree, so at least it
is able to proceed beyond that part of the pattern. I have
also stepped TableGen inside </span><span
style="font-family:"Courier New",serif"
lang="EN-US">gdb</span><span
style="font-family:"Ericsson Hilda"" lang="EN-US">
and verified that having Defs causes GlobalISel to include </span><span
style="font-family:"Courier New",serif"
lang="EN-US">CCReg</span><span
style="font-family:"Ericsson Hilda"" lang="EN-US">
in the </span><span style="font-family:"Courier
New",serif" lang="EN-US">Types</span><span
style="font-family:"Ericsson Hilda"" lang="EN-US">
field of the </span><span style="font-family:"Courier
New",serif" lang="EN-US">TreePatternNode</span><span
style="font-family:"Ericsson Hilda"" lang="EN-US">
corresponding to the instruction, which is what GlobalISel
looks at to subsequently reject the pattern on basis that
the instruction produces multiple results.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda"" lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda"" lang="EN-US">But from your comment, I take it
that the </span><span style="font-family:"Courier
New",serif" lang="EN-US">Defs</span><span
style="font-family:"Ericsson Hilda"" lang="EN-US">
field should never be considered actual output, is that
correct? If so, I find it strange that </span><span
style="font-family:"Courier New",serif"
lang="EN-US">CodeGenDAGPatterns</span><span
style="font-family:"Ericsson Hilda"" lang="EN-US">,
which parses the patterns, takes the CCReg into
consideration as additional results. I am tempted to modify
that part of the code, but maybe I’m missing some invariant
that’s not immediately evident…<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda"" lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda"" lang="EN-US">Cheers,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda"" lang="EN-US">Gabriel<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Ericsson
Hilda"" lang="EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span
style="mso-fareast-language:SV" lang="EN-US">From:</span></b><span
style="mso-fareast-language:SV" lang="EN-US"> Dominik
Montada <a class="moz-txt-link-rfc2396E" href="mailto:dominik.montada@hightec-rt.com"><dominik.montada@hightec-rt.com></a> <br>
<b>Sent:</b> den 4 juni 2020 14:51<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<b>Cc:</b> Gabriel Hjort Åkerlund
<a class="moz-txt-link-rfc2396E" href="mailto:gabriel.hjort.akerlund@ericsson.com"><gabriel.hjort.akerlund@ericsson.com></a><br>
<b>Subject:</b> Re: [llvm-dev] Nested instruction
patterns rejected by GlobalISel when having registers in
Defs<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p>Hi Gabriel,<span style="mso-fareast-language:SV"><o:p></o:p></span></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?<o:p></o:p></p>
<p>The command is <tt><span style="font-size:10.0pt">llvm-tblgen
-gen-global-isel <couple of -I flags>
<your_target>.td --write-if-changed
--warn-on-skipped-patterns</span></tt><o:p></o:p></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.<o:p></o:p></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.<o:p></o:p></p>
<p>Cheers,<o:p></o:p></p>
<p>Dominik<o:p></o:p></p>
<div>
<p class="MsoNormal">Am 04.06.20 um 14:34 schrieb Gabriel
Hjort Åkerlund via llvm-dev:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<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:</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-family:"Courier
New",serif" lang="EN-US">let ..., Defs = [CCReg] in</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-family:"Courier
New",serif" lang="EN-US">def shfts_a32_imm7:
Instruction<(outs OurRC:$dst), ...>;</span><o:p></o:p></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"> </span><o:p></o:p></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.:</span><o:p></o:p></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"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-line-height-alt:3.0pt"><span
style="font-size:10.0pt" lang="EN-US">def Pat<(source
pattern ...),</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-line-height-alt:3.0pt"><span
style="font-size:10.0pt" lang="EN-US"> (sext_a32
(INSERT_SUBREG (...), (shfts_a32_imm7 OurRC:$src,
Imm7:$imm), ...>;</span><o:p></o:p></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"> </span><o:p></o:p></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" 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" 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" 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.</span><o:p></o:p></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"> </span><o:p></o:p></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" 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"
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" 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?</span><o:p></o:p></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"> </span><o:p></o:p></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><o:p></o:p></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"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:SV"><br>
<br>
<o:p></o:p></span></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>LLVM Developers mailing list<o:p></o:p></pre>
<pre><a href="mailto:llvm-dev@lists.llvm.org" moz-do-not-send="true">llvm-dev@lists.llvm.org</a><o:p></o:p></pre>
<pre><a href="https://protect2.fireeye.com/v1/url?k=52e18446-0c413e28-52e1c4dd-86b1886cfa64-f424e731a80348bd&q=1&e=238953c8-f0ec-4510-8c97-620bfb03d5be&u=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></pre>
</blockquote>
<pre>-- <o:p></o:p></pre>
<pre>----------------------------------------------------------------------<o:p></o:p></pre>
<pre>Dominik Montada Email: <a href="mailto:dominik.montada@hightec-rt.com" moz-do-not-send="true">dominik.montada@hightec-rt.com</a><o:p></o:p></pre>
<pre>HighTec EDV-Systeme GmbH Phone: +49 681 92613 19<o:p></o:p></pre>
<pre>Europaallee 19 Fax: +49-681-92613-26<o:p></o:p></pre>
<pre>D-66113 Saarbrücken WWW: <a href="https://protect2.fireeye.com/v1/url?k=a0228059-fe823a37-a022c0c2-86b1886cfa64-48b7aa6978940111&q=1&e=238953c8-f0ec-4510-8c97-620bfb03d5be&u=http%3A%2F%2Fwww.hightec-rt.com%2F" moz-do-not-send="true">http://www.hightec-rt.com</a><o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Managing Director: Vera Strothmann<o:p></o:p></pre>
<pre>Register Court: Saarbrücken, HRB 10445, VAT ID: DE 138344222<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>This e-mail may contain confidential and/or privileged information. If<o:p></o:p></pre>
<pre>you are not the intended recipient please notify the sender immediately<o:p></o:p></pre>
<pre>and destroy this e-mail. Any unauthorised copying, disclosure or<o:p></o:p></pre>
<pre>distribution of the material in this e-mail is strictly forbidden.<o:p></o:p></pre>
<pre>--- <o:p></o:p></pre>
</div>
</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>