[llvm-dev] Preventing function call from being optimized out in LTO

David Blaikie via llvm-dev llvm-dev at lists.llvm.org
Tue Jun 9 12:12:23 PDT 2020


On Tue, Jun 9, 2020 at 11:54 AM Shishir V Jessu <shishir.jessu at utexas.edu>
wrote:

> Hi David,
>
> By "dead" do you mean unreachable?
>

Yep!


> My understanding was that the removal of dead code is simply another
> optimization,
>

It is, yes.


> which should be disabled after adding "optnone"
>

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.


> (and adding the function to llvm.used so the function doesn't later get
> deleted entirely).
>

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.


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

Hmm, can't quite picture that from what you've described, sorry.


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

Any number of optimizations might make more code provably dead & then
removed, losing your calls.

- Dave


>
> If you have any more insight I'd appreciate it! Thanks for your help.
>
> On Tue, Jun 9, 2020 at 1:13 PM David Blaikie <dblaikie at gmail.com> wrote:
>
>> 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?
>>
>> On Tue, Jun 9, 2020 at 11:01 AM Shishir V Jessu via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Hello,
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> How can I ensure that none of the calls I add are optimized out? Thanks
>>> for your help!
>>>
>>> Best,
>>> Shishir Jessu
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200609/1a7ed696/attachment.html>


More information about the llvm-dev mailing list