[llvm] r293799 - [IPSCCP] Don't propagate return values of functions marked as noinline.

Davide Italiano via llvm-commits llvm-commits at lists.llvm.org
Wed Feb 1 16:44:24 PST 2017

On Wed, Feb 1, 2017 at 4:33 PM, Davide Italiano <davide at freebsd.org> wrote:
> On Wed, Feb 1, 2017 at 4:06 PM, Friedman, Eli <efriedma at codeaurora.org> wrote:
>> On 2/1/2017 10:52 AM, Davide Italiano via llvm-commits wrote:
>>> Author: davide
>>> Date: Wed Feb  1 12:52:20 2017
>>> New Revision: 293799
>>> URL: http://llvm.org/viewvc/llvm-project?rev=293799&view=rev
>>> Log:
>>> [IPSCCP] Don't propagate return values of functions marked as noinline.
>>> This tries to address what Hal defined (in the post-commit review of
>>> r293727) a long-standing problem with noinline, where we end up
>>> de facto inlining trivial functions e.g.
>>> __attribute__((noinline)) int patatino(void) { return 5; }
>>> because of return value propagation.
>> I'm not really following why this is a problem in the first place...
>> noinline doesn't mean "don't do any interprodedural optimizations". And if
>> we did want it to mean that, we should do it in a more principled manner
>> than scattering checks across each individual pass.
>  + Hal.
> Thanks for your comment, Eli.
> Do you have any ideas on how to handle this more systematically? The
> main reason why I special cased this for IPSCCP is that I wasn't able
> to think of other passes being able to produce a similar effect (I
> personally don't have a strong opinion whether we should prevent the
> transformation in this case or not, maybe it's worth discussing this
> on llvm-dev).
> --
> Davide

FWIW, I checked what GCC does (but didn't check how they implement
this), and it seems they keep the call in the __noinline__
case: https://godbolt.org/g/FndcjY



"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare

More information about the llvm-commits mailing list