[llvm] r293799 - [IPSCCP] Don't propagate return values of functions marked as noinline.
Hal Finkel via llvm-commits
llvm-commits at lists.llvm.org
Sat Feb 4 14:02:10 PST 2017
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.
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.
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
More information about the llvm-commits