[PATCH] D14227: Add a new attribute: norecurse

[James Molloy via llvm-commits]

Morning all,

It feels like we're getting closer to consensus on this. Off-list, Aaron
was happy that this isn't going to cause a proliferation of norecurse in
the clang code generator - the general use case would be for LLVM to infer
norecurse itself in FunctionAttrs and only in exceptional cases would clang
have to step in (such as main in C++).

David, The only thing that could break norecurse is if some transform
actually went and added new call edges (to non-intrinsic/builtin
functions). I can't think of a transform that would do this, but if it does
it does seem that would be exceptional and so making the transform remove
the norecurse attribute seems reasonable to me.

What do you think?

Cheers,

James
On Mon, 2 Nov 2015 at 21:34 Mehdi AMINI via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> joker.eph added a comment.
>
> The fact that a transformation may invalidate the attribute seems to me to
> be independent from wether we infer it or not: the same example you took
> could come from a specific front-end (or directly a user) adding the
> attributes. I think we'll have to teach such a transformation that
> invalidate the attribute to either not perform when the attribute is
> present, or remove it. Does it makes sense?
> Do you foresee a lot of such transformations? Or cases where it would be
> hard to do?
>
>
> 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/20151103/ff5c8503/attachment.html>