[PATCH] Prevent user-supplied libc implementations from premature removal in LTO

Nick Lewycky nlewycky at google.com
Tue Nov 5 11:01:49 PST 2013


On 5 November 2013 09:53, Duncan Exon Smith <dexonsmith at apple.com> wrote:

> On Nov 4, 2013, at 6:20 PM, Rafael EspĂ­ndola <rafael.espindola at gmail.com>
> wrote:
>
> > I think this patch is OK with those changes.
>
> Final (?) patch attached.
>

    void applyRestriction(llvm::GlobalValue &GV,
+                        const llvm::TargetLibraryInfo& TLI,
                         std::vector<const char*> &MustPreserveList,
                         llvm::SmallPtrSet<llvm::GlobalValue*, 8> &AsmUsed,
                         llvm::Mangler &Mangler);

One of these is not like the others. Please put the & next to the variable
name instead of the type.

+  LibFunc::Func f;
+  if (isa<Function>(GV) && TLI.getLibFunc(GV.getName(), f))

I don't think this is right, and I'm not sure how to fix it. If you say
-fno-builtin for example, we won't add anything to this list. So, the
compiler may delete your user-supplied memcpy, then the  backend will add
calls to memcpy.

+target triple = "x86_64-apple-clang"

"clang" is not a part of a triple. How about "x86_64-apple-darwin9"?

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131105/7ea5ed1a/attachment.html>


More information about the llvm-commits mailing list