[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