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

[Hal Finkel via llvm-commits]

On 02/04/2017 03:25 PM, Sanjoy Das wrote:
> What about DCE'ing a readnone/readonly & nounwind function?  Does that
> also not "look like inlining" via this kind of reasoning?

I think this could go either way. Are we propagating out that the 
function "does nothing" or "does not do anything"?

  -Hal

>
> -- Sanjoy
>
> On Wed, Feb 1, 2017 at 10:07 PM, Hal Finkel via llvm-commits
> <llvm-commits at lists.llvm.org> wrote:
>> On 02/01/2017 06:06 PM, Friedman, Eli via llvm-commits 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"
>>
>> Agreed. To be fair, this is exactly what I've told people in the past to
>> explain this behavior. After years of doing this, I've convinced myself that
>> it is actually not right in this case.
>>
>>> . 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.
>>
>> I don't think there is a more-principled way of doing this. Obviously, we
>> need to decide what is inlining and how that differs from other IPO. Here
>> are my thoughts:
>>
>>   1. inlining means taking a function body, or any part of a function body,
>> and placing it in the function's callers. In short, propagating information
>> about what the function affirmatively does to its callers.
>>
>>   2. This is qualitatively different from propagating information to the
>> callers about things the function does not do (e.g. does not access memory).
>>
>>   3. return-value propagation falls into this first category (it is an
>> affirmative information propagation to the caller), and thus should be
>> disabled by noinline
>>
>> If I have a function which is defined as { return 5; }, and marked noinline,
>> then the '5' only appears in the function. If the '5' is put in the callers,
>> then we've inlined (at least partially) the function. noinline should
>> prevent that. Most of our IPO does not do this, but rather, determines
>> things the functions don't do.
>>
>> Thanks again,
>> Hal
>>
>>> -Eli
>>>
>> --
>> Hal Finkel
>> Lead, Compiler Technology and Programming Languages
>> Leadership Computing Facility
>> Argonne National Laboratory
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory