<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>