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

[Shishir V Jessu via llvm-dev]

Hi Tobias,

Thanks for your response! I was doing this as well, but it turns out
adding  __attribute__((used)) prevents the function itself from being
removed, but does not prevent *all calls to the function* from being
removed, which is what I was after. I fixed it by changing some IR that was
resulting in unconditionally dead branches ("br i1 false").

Best,
Shishir

On Wed, Jun 10, 2020 at 1:04 AM Tobias Hieta <tobias at plexapp.com> wrote:

> I don't know about calling the internal IR stuff directly - but when I ran
> into this in C code I added  __attribute__((used)) to the function to not
> have it be optimized out.
>
> On Tue, Jun 9, 2020 at 8:01 PM 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/20200614/a6c152f5/attachment.html>