[llvm-dev] How to prevent optimizing away a call + its arguments

Davide Italiano via llvm-dev llvm-dev at lists.llvm.org
Thu Jun 22 10:41:34 PDT 2017


On Jun 22, 2017 10:36 AM, "David Blaikie via llvm-dev" <
llvm-dev at lists.llvm.org> wrote:

optnone should work, but really noinline should probably (Chandler: Can you
confirm: is it reasonable to model noinline as "no interprocedural analysis
across this function boundary" (so FunctionAttrs should do the same thing
for noinline as it does for optnone, for example? ie: not derive any new
attributes) - allowing the function to be optimized internally (unlike
optnone) but not allowing interprocedural analysis inside the function to
be used in callers (unlike optnone)) work as well?



IMHO, No. The only semantic of noinline is that the inliner(s) pass
shouldn't do anything with that function. Inhibiting IPO seems like could
be a valid usecase but that would need a different attribute (e.g. noipo).

--
Davide



On Thu, Jun 22, 2017 at 7:35 AM Joerg Sonnenberger via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Wed, Jun 21, 2017 at 05:25:04PM -0700, Mehdi AMINI via llvm-dev wrote:
> > Hi Kuba,
> >
> > Try:
> >
> > __attribute__(optnone)
> >
> > See
> > https://clang.llvm.org/docs/AttributeReference.html#
> optnone-clang-optnone
>
> Actually, it should be enough to use:
>
> __attribute__((noinline))
> void please_do_not_optimize_me_away(int arg1, void *arg2) {
>   asm volatile("":::"memory");
> }
>
> Creating a real barrier is important.
>
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
http://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/20170622/804a8b08/attachment.html>


More information about the llvm-dev mailing list