[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:52:53 PST 2017


On Wed, Feb 1, 2017 at 4:44 PM, Davide Italiano <davide at freebsd.org> wrote:
> 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
>

Sorry, spoke too early. I passed `-fno-inline-functions` to GCC to
prevent inlining and I actually noticed the value gets propagated
anyway. I'll rollback to the older behaviour for now, and we can
continue the discussion in the meanwhile.

-- 
Davide

"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