<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<p>My second point should still stand. Not caring about the MI
representation does simplify the work involved, so that's a good
observation.</p>
<p>Philip<br>
</p>
<div class="moz-cite-prefix">On 5/25/21 11:58 PM, Markus Lavin
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:VI1PR07MB6128068C580DD63272072675E8249@VI1PR07MB6128.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-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}@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;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
font-size:10.0pt;
font-family:"Courier New";}span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}div.WordSection1
{page:WordSection1;}ol
{margin-bottom:0cm;}ul
{margin-bottom:0cm;}</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="mso-fareast-language:EN-US"
lang="EN-US">That is correct. The only use case I am
interested in is when AA is queried during scheduling of MI
and as Bjorn points out (and afaiu) this falls back on
assumes being present in the IR. The fact that AA, during
the MI layer, falls back on IR can indeed seem a bit strange
but that is simply how it works and not directly related to
the presence of assumes or not.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="EN-US">AFAIU llvm.assume will iselect to nothing
(which effectively also eliminates its predecessors if the
llvm.assume was their only use) so at least for this use
case no explicit llvm.assume representation is required in
the MI layer. The requirement would possibly be different if
there were other uses of llvm.assume in the MI layer but I
am not sure what they would be.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="EN-US">-Markus<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm
0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span
lang="EN-US"> Björn Pettersson A
<a class="moz-txt-link-rfc2396E" href="mailto:bjorn.a.pettersson@ericsson.com"><bjorn.a.pettersson@ericsson.com></a>
<br>
<b>Sent:</b> den 25 maj 2021 20:39<br>
<b>To:</b> Philip Reames
<a class="moz-txt-link-rfc2396E" href="mailto:listmail@philipreames.com"><listmail@philipreames.com></a>; Markus Lavin
<a class="moz-txt-link-rfc2396E" href="mailto:markus.lavin@ericsson.com"><markus.lavin@ericsson.com></a>; <a class="moz-txt-link-abbreviated" href="mailto:jannh@google.com">jannh@google.com</a>;
<a class="moz-txt-link-abbreviated" href="mailto:nikita.ppv@gmail.com">nikita.ppv@gmail.com</a>; llvm-dev
<a class="moz-txt-link-rfc2396E" href="mailto:llvm-dev@lists.llvm.org"><llvm-dev@lists.llvm.org></a><br>
<b>Subject:</b> RE: [llvm-dev] llvm.assume after
CodeGenPrepare<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US">I think Markus use
case is that MachineInstr::mayAlias may use AA (and even
possibly TBAA), and AA could make use of llvm.assume to
make decisions.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">So the alias analysis
in cadegen is partly based on analysing the “final” IR
representation before ISel, so the llvm.assume does not
need to be present in the MI layer for that to work.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">PS. It might seem a
bit strange and dangerous to use the IR and IR analyses
during the codegen (e.g. afte PHI elimination), but afaik
it works as long as MachineMemOperands are handled
correctly (being dropped or updated correctly when doing
certain transforms such as store merging).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">/Björn<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue
1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span
lang="EN-US"> llvm-dev <<a
href="mailto:llvm-dev-bounces@lists.llvm.org"
moz-do-not-send="true">llvm-dev-bounces@lists.llvm.org</a>>
<b>On Behalf Of </b>Philip Reames via llvm-dev<br>
<b>Sent:</b> den 25 maj 2021 17:42<br>
<b>To:</b> Markus Lavin <<a
href="mailto:markus.lavin@ericsson.com"
moz-do-not-send="true">markus.lavin@ericsson.com</a>>;
llvm-dev <<a
href="mailto:llvm-dev@lists.llvm.org"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>;
<a href="mailto:jannh@google.com"
moz-do-not-send="true">jannh@google.com</a>; <a
href="mailto:nikita.ppv@gmail.com"
moz-do-not-send="true">
nikita.ppv@gmail.com</a><br>
<b>Subject:</b> Re: [llvm-dev] llvm.assume after
CodeGenPrepare<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p><span lang="EN-US">I think there's two interacting pieces
here:<o:p></o:p></span></p>
<ul type="disc">
<li class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0
level1 lfo3">
<span lang="EN-US">I don't believe we have a way to
represent an assume at the MI layer. If we let them
flow through codegen, we'd need to add such a thing.<o:p></o:p></span></li>
<li class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0
level1 lfo3">
<span lang="EN-US">The tradeoffs between information
preservation and lowering may be different at
different points in the pipeline. Johannes frames
this as a canonicalization problem. That sounds
reasonable, but it's also reasonable that we may need
to give up on preserving assumes at some point. (As a
silly example, we probably don't want them at MC.)
Where exactly that point is unclear, and is mostly a
matter of practical engineering tradeoffs.<o:p></o:p></span></li>
</ul>
<p><span lang="EN-US">If you felt like exploring alternate
lowering points, that would seem entirely reasonable.
It might not work out, or it might require a bunch of
work to make happen, but the basic idea seems entirely
worth exploring.<o:p></o:p></span></p>
<p><span lang="EN-US">Philip<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">On 5/25/21 3:11
AM, Markus Lavin via llvm-dev wrote:<o:p></o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span lang="EN-US">With recent
changes in BasicAA (mostly by Nikita Popov I believe)
llvm.assumes can now guide in the AA decision making.
Which is of course great. <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">For example for C
input (or IR equivalent) as follows it can make a huge
difference if the variable ‘x’ is known to be non-zero
when AA is queried during scheduling<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">__builtin_assume(x
!= 0);<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">for (int i = 0; i
< 64; i += 4) {<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> v[(i + 0) * x] =
v[(i + 0) * x] >> 2;<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> v[(i + 1) * x] =
v[(i + 1) * x] >> 2;<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> v[(i + 2) * x] =
v[(i + 2) * x] >> 2;<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> v[(i + 3) * x] =
v[(i + 3) * x] >> 2;<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">}<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Unfortunately it
appears that the CodeGenPrepare pass removes
llvm.assume so that they never reach the code
generator. Currently commit 91c9dee3fb6d89ab3 (and
before that commit 6d20937c29a1a1d67) eliminate
assumptions in CodeGenPrepare for reasons that appear
to be optimization (avoiding blocks that would be
empty if it was not for the llvm.assume and its
predecessors).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">It seems these two
efforts are quite contradictory. Is there any deeper
thinking behind this? I for one would be in favor of
not eliminating assumes.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">-Markus<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span
lang="EN-US"><o:p> </o:p></span></p>
<pre><span lang="EN-US">_______________________________________________<o:p></o:p></span></pre>
<pre><span lang="EN-US">LLVM Developers mailing list<o:p></o:p></span></pre>
<pre><span lang="EN-US"><a href="mailto:llvm-dev@lists.llvm.org" moz-do-not-send="true">llvm-dev@lists.llvm.org</a><o:p></o:p></span></pre>
<pre><span lang="EN-US"><a href="https://protect2.fireeye.com/v1/url?k=efdd418c-b0467bc9-efdd0117-867b36d1634c-7a75399069504f9e&q=1&e=17991efb-205e-4418-bc44-152a2fed67d4&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></span></pre>
</blockquote>
</div>
</div>
</div>
</blockquote>
</body>
</html>