[PATCH] D14228: [FunctionAttrs] Identify norecurse functions

James Molloy via llvm-commits llvm-commits at lists.llvm.org
Sat Nov 7 12:36:42 PST 2015


Hi Mehdi,

I think that might not be sufficient, but I'm prepared to be convince
otherwise.

Consider F with call sites in two functions : A and B. Even if A and B are
norecurse, there is no guarantee we can't do something like: A -> F -> B ->
F, right? Or actually that should show up in the SCC, so that can't happen
...

... So I've just convinced myself that you're right :) I'll loosen the code
slightly.

James
On Fri, 6 Nov 2015 at 17:39, Manman Ren via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> manmanren added inline comments.
>
> ================
> Comment at: lib/Transforms/IPO/FunctionAttrs.cpp:1778
> @@ +1777,3 @@
> +  // If F is internal, has only one use and that use of F is a norecurse
> +  // function, then F is also norecurse.
> +  if (F->hasOneUse() && F->hasInternalLinkage())
> ----------------
> joker.eph wrote:
> > Why one use? If F has multiple callers but they are all "norecurse",
> shouldn't it be enough?
> During bottom-up traversal, have the uses of F been visited and possibly
> marked as norecurse?
>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D14228
>
>
>
> _______________________________________________
> 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/20151107/1f3ef401/attachment.html>


More information about the llvm-commits mailing list