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

[Hal Finkel via llvm-commits]

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