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

[Hal Finkel via llvm-commits]

On 02/04/2017 03:45 PM, Davide Italiano wrote:
> On Sat, Feb 4, 2017 at 1:25 PM, Sanjoy Das
> <sanjoy at playingwithpointers.com> wrote:
>> What about DCE'ing a readnone/readonly & nounwind function?  Does that
>> also not "look like inlining" via this kind of reasoning?
>>
>> -- Sanjoy
>>
> It probably depends on the semantic we want to give to the attributes.
> I finally cleared my mind after discussing this with Chandler/David
> Majnemer at the LLVM social.
> I convinced myself that "noinline" has actually one single semantic
> which is "the inliner pass can't inline this function".

This is a source-level attribute, and we should not define these in 
terms of our internal infrastructure (unless there is no other option). 
Should it apply to a "proper" partial-inlining pass?

> What other passes do is probably unrelated and to block return value
> propagation we should use a different attribute (e.g.
> __attribute((noipo))).

I'd be happy with this too.

> That said I think we shouldn't do that, and consumers who want to
> block optimizations should use __attribute__((optnone)) instead.

I don't think this works because we often do want optimization of both 
the caller and callee.

Thanks again,
Hal

>
> Thanks!
>

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