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

[Davide Italiano via llvm-commits]

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

Thanks,

-- 
Davide

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