[PATCH] Prevent user-supplied libc implementations from premature removal in LTO
rafael.espindola at gmail.com
Mon Nov 11 12:50:13 PST 2013
+//===-- CodeGen/RuntimeLibcalls.h - Runtime Library Calls --------*-
Nice cleanup, but unrelated. Please commit it independently.
+ const std::vector<llvm::StringRef> &Libcalls,
Can you use an ArrayRef?
+ std::sort(Libcalls.begin(), Libcalls.end());
+ Libcalls.erase(std::unique(Libcalls.begin(), Libcalls.end()),
What is the size of this std::vector? Would a StringSet be better?
+; RUN: FileCheck <%t3 %s -check-prefix=LIBC
+; RUN: FileCheck <%t3 %s -check-prefix=RT
+; RUN: FileCheck <%t3 %s -check-prefix=BOTH
+; RUN: FileCheck <%t3 %s -check-prefix=NEITHER
You only need 2 prefixes, one for the keep and one for the NOT.
FileCheck also just got support for multiple prefixes in one run, so
you should be able to use just one FileCheck invocation with two
Nick, what do you think of the idea of using TargetLibraryInfo and
On 11 November 2013 12:12, Duncan Exon Smith <dexonsmith at apple.com> wrote:
> On Nov 5, 2013, at 4:59 PM, Duncan Exon Smith <dexonsmith at apple.com> wrote:
>> On Nov 5, 2013, at 3:29 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>>>> What if I update the patch to have libLTO check against both TLI and TargetLowering? It wouldn't provide a new interface, but it seems to solve the problem at hand.
>>> That is probably OK.
>> Okay, check this out then.
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
More information about the llvm-commits