<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">The IR you provide is actually
incorrect. The "tobeinlined" function is external, so there's no
way even in theory to assert that it's always inlined.<br>
<br>
We could consider relaxing the verifier to allow this case, but
doing that seems problematic. In particular, why stop at one
level of inlining? We really don't want the verify to have to be
walking back through the entire call graph to verify the required
property. <br>
<br>
We could also relax the definition of mustail. To do this, we'd
need to carefully consider whether there's a tweak to our
definition of musttail which is sufficient without loosing to much
error diagnostics or optimization power. Any suggestions on
specific revisions here?<br>
<br>
The current restriction on mustail -- specifically matching
signatures -- is stronger than it needs to be in. You could
consider enhancing the backends to lower tailcalls with signature
mismatches and then extend the verify to allow those cases. That
would be a way around your problem indirectly.<br>
<br>
Philip<br>
<br>
On 06/24/2017 08:21 AM, Siddharth Bhat via llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAPipc=0-+pM3yTB=NHkV+y_FG3Hx5mC1njmrBh6HGRPRkZcUjg@mail.gmail.com">
<div dir="ltr">
<div>Consider this program:</div>
<div><br>
</div>
<div><font face="monospace">@globalSideEffect = global i32 0</font></div>
<div><font face="monospace"><br>
</font></div>
<div><font face="monospace">define void @tobeinlined() #0 {</font></div>
<div><font face="monospace">entry:</font></div>
<div><font face="monospace"> store i32 3, i32*
@globalSideEffect, align 4</font></div>
<div><font face="monospace"> musttail call fastcc void
@tailcallee(i32 3)</font></div>
<div><font face="monospace"> ret void</font></div>
<div><font face="monospace">}</font></div>
<div><font face="monospace"><br>
</font></div>
<div><font face="monospace">define fastcc void @tailcallee(i32
%i) {</font></div>
<div><font face="monospace">entry:</font></div>
<div><font face="monospace"> call void @tobeinlined()</font></div>
<div><font face="monospace"> ret void</font></div>
<div><font face="monospace"><br>
</font></div>
<div><font face="monospace">}</font></div>
<div><font face="monospace"><br>
</font></div>
<div><font face="monospace">attributes #0 = { alwaysinline }</font></div>
<div><font face="monospace"><br>
</font></div>
<div>Clearly, if this is processed with <font face="monospace">opt
-alwaysinline, </font>it will lead to a correct tail call
since the call to<font face="monospace"> "tobeinlined" </font>will
be inlined. </div>
<div><font face="monospace"><br>
</font></div>
<div>However, because <font face="monospace">opt </font>checks
for the correctness of the module when it is being loaded, it
fails the <font face="monospace">verifyModule() </font>check
with:</div>
<div><font face="monospace"><br>
</font></div>
<div><font face="monospace"><br>
</font></div>
<div>
<div style="font-family:monospace">cannot guarantee tail call
due to mismatched parameter counts</div>
<div style="font-family:monospace"> musttail call fastcc void
@tailcallee(i32 3)</div>
<div style="font-family:monospace">opt: prelude.inlined.ll:
error: input module is broken!</div>
<div style="font-family:monospace"><br>
</div>
<div>These are just experiment, but I suspect that I will have
the same problem when I am constructing IR with the LLVM
API: That is, the <font face="monospace">verifyModule</font>
sanity check will cause the IR to be considered illegal, <i>even
though the final IR that would have been generated will be
correct.</i></div>
</div>
<div><i><br>
</i></div>
<div>What is the correct solution to this when I'm
programatically generating IR?</div>
<div><br>
</div>
<div>I was considering:</div>
<div><br>
</div>
<div>1. generate calls with <font face="monospace">tail</font>,
not<font face="monospace"> musttail</font></div>
<div>2. Apply <font face="monospace">AlwaysInline</font> pass
to Module</div>
<div>3. Walk module and replace <font face="monospace">tail</font>
with <font face="monospace">musttail</font></div>
<div>4. Apply <font face="monospace">VerifyModule</font> to
sanity check</div>
<div><br>
</div>
<div>However, that seems like somewhat of a hack. Is there a
nicer solution? Will what I'm trying "just work"?</div>
<div><br>
</div>
<div>Thanks,</div>
<div>~Siddharth</div>
<div><br>
</div>
</div>
<div dir="ltr">-- <br>
</div>
<div data-smartmail="gmail_signature">
<div dir="ltr">Sending this from my phone, please excuse any
typos!</div>
</div>
<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>
<p><br>
</p>
</body>
</html>