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

[Sanjoy Das via llvm-commits]

What about DCE'ing a readnone/readonly & nounwind function?  Does that
also not "look like inlining" via this kind of reasoning?

-- 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