[PATCH] D14227: Add a new attribute: norecurse

[James Molloy via llvm-commits]

Hi David,

So in that case it would be legal for f() to be marked norecurse (although
my implementation in FunctionAttrs is more conservative than that, but
that's what the LangRef says). However I'm not sure exactly how inlining
could break this assumption - recursive inlining would end up with
something like (modifying your testcase slightly):

f() {
  a()
  g()
}

g() {
  a()
  g()
}


which doesn't break at all.

James

On Mon, 2 Nov 2015 at 20:39 David Majnemer via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> majnemer added a subscriber: majnemer.
> majnemer added a comment.
>
> James,
>
> Have you considered what happens with something along the lines of:
>
>   void f() {
>     g();
>   }
>   void g() {
>     g();
>   }
>
> In this case, we can clearly see that `f` doesn't recurse onto itself but
> `g` does.
>
> I am concerned that if we infer `norecurse`, we will hit cases where
> transformations along the lines of inlining invalidate the attribute.
>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D14227
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151102/c6ffe379/attachment.html>