[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