<div dir="ltr">Hi Paul, <br><br>Thanks for your help! I was able to rewrite that section of IR so it didn't produce a 'false' test, which indeed fixed the problem. <br><br>Best, <br>Shishir</div><img src="https://my-email-signature.link/signature.gif?u=452460&e=100359166&v=9edc4007b25df50660691a6c885253dda5efa148c52eb57585185f3c78694a55" style="width:2px;max-height:0;overflow:hidden"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 10, 2020 at 8:09 AM Robinson, Paul <<a href="mailto:paul.robinson@sony.com">paul.robinson@sony.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div class="gmail-m_7502744279287703971WordSection1">
<p class="MsoNormal">Right, -O0/optnone is not actually completely free of optimization; the goal I believe is to compile quickly, producing code that is easy to debug. In this case, `br i1 false` can be cheaply transformed into an unconditional branch, which
makes the `cont:` block have no predecessors, and pruning an entire block with no predecessors is also cheap (certainly cheaper than generating code for all those blocks). This cascades through the successors to `cont:`.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Looking at why that conditional branch has a `false` test would be the most productive path, I think.<u></u><u></u></p>
<p class="MsoNormal">--paulr<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-top:none;border-right:none;border-bottom:none;border-left:1.5pt solid blue;padding:0in 0in 0in 4pt">
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> <br>
<b>Sent:</b> Tuesday, June 9, 2020 7:09 PM<br>
<b>To:</b> Shishir V Jessu <<a href="mailto:shishir.jessu@utexas.edu" target="_blank">shishir.jessu@utexas.edu</a>>; Robinson, Paul <<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>><br>
<b>Cc:</b> llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Subject:</b> Re: [llvm-dev] Preventing function call from being optimized out in LTO<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Tue, Jun 9, 2020 at 2:32 PM Shishir V Jessu <<a href="mailto:shishir.jessu@utexas.edu" target="_blank">shishir.jessu@utexas.edu</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">Hi David, <br>
<br>
Sure! Here's a function in sqlite3 called verifyDbFile, compiled with -O3. This is what it looks like when the intermediate bitcode is emitted by clang:
<a href="https://urldefense.com/v3/__https:/pastebin.com/L3PrK1ac__;!!JmoZiZGBv3RvKRSx!qznGGDbOGxHy0g2fycTZSX8H71lUsCtyJO3DWQcKvjjJxveeAn_5liG1jBCQGzHXWA$" target="_blank">
link</a><br>
<br>
And here's what happens after I run opt -O3 (no additional command-line arguments) on the file containing this function:
<a href="https://urldefense.com/v3/__https:/pastebin.com/rZHBm2iU__;!!JmoZiZGBv3RvKRSx!qznGGDbOGxHy0g2fycTZSX8H71lUsCtyJO3DWQcKvjjJxveeAn_5liG1jBDvSbH5IQ$" target="_blank">
link</a>. <br>
<br>
I'm not 100% sure, but it seems like some pass within opt determines that a particular trap is guaranteed to occur on line 22, and so optimizes out the rest of the function, even though the pre-opt version of the function has the "optnone" attribute.
<br>
<br>
Does this seem like intended behavior or some sort of bug? Is there any way to disable this behavior? Thanks!<u></u><u></u></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><br>
Ah, OK, so the call is unconditionally dead based on local reasoning within the function - not sure if that qualifies as a bug in the optnone implementation. Even at -O0, we do some optimizations - just designed to be benign ones, from a program behavior/debugging
perspective, I suppose. <br>
<br>
<a href="mailto:paul.robinson@sony.com" target="_blank">+Paul Robinson</a> who had some hand in the implementation of optnone, to see how he feels about it/whether he reckons removing dead code at -O0/optnone is desirable or not.<br>
<br>
But otherwise, if you can make the code not dead, that would thwart any optimizations - eg: loading from a volatile variable (that could always be false in reality) to determine the condition to branch to the code you want to preserve.<br>
<br>
- David<br>
<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal"><br>
Best, <br>
Shishir<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">On Tue, Jun 9, 2020 at 3:53 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">On Tue, Jun 9, 2020 at 1:29 PM Shishir V Jessu <<a href="mailto:shishir.jessu@utexas.edu" target="_blank">shishir.jessu@utexas.edu</a>> wrote:<br>
><br>
> Hi David,<br>
><br>
> Thanks for your detailed comments.<br>
><br>
>> but without any interprocedural analysis, nor any optimization of the body of the function, a call to an optnone function can still be removed if the call is dead.<br>
><br>
><br>
> I am not concerned with calls to an optnone function being removed, but rather call-sites within an optnone function being removed. But although I place "optnone" on a given function F, dead code in F still sometimes seems to be potentially removed. Is there
any way to prevent this from happening at the linking stage (since the bitcode emitted by clang still includes all my calls)?<br>
<br>
Oh, sorry - my misunderstanding. Could you provide an example of that<br>
happening? (a specific optnone function IR and a specific 'opt'<br>
command that optimizes that IR and modifies the optnone function in an<br>
unexpected/undesirable way) - that could be a bug.<br>
<br>
- Dave<br>
<br>
><br>
> Thanks,<br>
> Shishir<br>
><br>
> On Tue, Jun 9, 2020 at 2:12 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
>><br>
>> On Tue, Jun 9, 2020 at 11:54 AM Shishir V Jessu <<a href="mailto:shishir.jessu@utexas.edu" target="_blank">shishir.jessu@utexas.edu</a>> wrote:<br>
>>><br>
>>> Hi David,<br>
>>><br>
>>> By "dead" do you mean unreachable?<br>
>><br>
>><br>
>> Yep!<br>
>><br>
>>><br>
>>> My understanding was that the removal of dead code is simply another optimization,<br>
>><br>
>><br>
>> It is, yes.<br>
>><br>
>>><br>
>>> which should be disabled after adding "optnone"<br>
>><br>
>><br>
>> Nah - optnone just means "don't optimize this function" (nor do interprocedural analysis to optimize the call site based on details of the implementation of this function - treat it as though this function were in another translation unit/module that the
compiler has no visibility into) - but without any interprocedural analysis, nor any optimization of the body of the function, a call to an optnone function can still be removed if the call is dead.<br>
>><br>
>>><br>
>>> (and adding the function to llvm.used so the function doesn't later get deleted entirely).<br>
>><br>
>><br>
>> llvm.used is there to preserve functions that don't otherwise need to exist - it sounds to me like this isn't a useful tool for your situation - if you manage to preserve the call then the function will be retained (unless it's defined as "available externally"
- then the definition of the funcion could be removed, leaving only a declaration). It sounds like you need to preserve the call - so if you succeed at that, then the function body/definition should be retained without the need for llvm.used.<br>
>><br>
>>><br>
>>> I am instrumenting certain basic blocks in an LLVM pass, and would like to compile a binary which structures things the same way the LLVM pass does, to analyze some behavior.<br>
>><br>
>><br>
>> Hmm, can't quite picture that from what you've described, sorry.<br>
>><br>
>>><br>
>>> I observe that my calls are not removed on -O0 and -O1 for several programs, so it should be the case that the calls are removed on higher optimization levels - but then adding "optnone" isn't protecting all of those calls from being removed.<br>
>><br>
>><br>
>> Any number of optimizations might make more code provably dead & then removed, losing your calls.<br>
>><br>
>> - Dave<br>
>><br>
>>><br>
>>><br>
>>> If you have any more insight I'd appreciate it! Thanks for your help.<br>
>>><br>
>>> On Tue, Jun 9, 2020 at 1:13 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
>>>><br>
>>>> optnone on such functions should suffice - well, unless the calls turn out to be dead & I don't think there's anything you can do to thwart dead code removal. So what are you trying to preserve the function calls for?<br>
>>>><br>
>>>> On Tue, Jun 9, 2020 at 11:01 AM Shishir V Jessu via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>>>>><br>
>>>>> Hello,<br>
>>>>><br>
>>>>> I am adding function calls to an LLVM link-time optimization (LTO) pass, using the IRBuilder::CreateCall method. I want these calls to remain in the final x86 binary at any optimization level, but on levels -O2 and -O3, some of these calls are being optimized
out.<br>
>>>>><br>
>>>>> So far, I've tried adding each function in the program (excluding LLVM intrinsics) to the llvm.used set, and I've also set noinline and optnone attributes on each function in the program. This has allowed me to retain most, but not all, of the calls I've
added with IRBuilder::CreateCall.<br>
>>>>><br>
>>>>> Furthermore, I have confirmed that all the calls I've created are present in the LLVM IR that results immediately after my pass. Thus, I know some future LTO pass is optimizing out some of these calls.<br>
>>>>><br>
>>>>> How can I ensure that none of the calls I add are optimized out? Thanks for your help!<br>
>>>>><br>
>>>>> Best,<br>
>>>>> Shishir Jessu<br>
>>>>> _______________________________________________<br>
>>>>> LLVM Developers mailing list<br>
>>>>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>>>>> <a href="https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!qznGGDbOGxHy0g2fycTZSX8H71lUsCtyJO3DWQcKvjjJxveeAn_5liG1jBDP_YGHlQ$" target="_blank">
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><u></u><u></u></p>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote></div>