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

Davide Italiano via llvm-commits llvm-commits at lists.llvm.org
Sat Feb 4 13:45:51 PST 2017

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".
What other passes do is probably unrelated and to block return value
propagation we should use a different attribute (e.g.
That said I think we shouldn't do that, and consumers who want to
block optimizations should use __attribute__((optnone)) instead.



"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare

More information about the llvm-commits mailing list