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

Rafael EspĂ­ndola rafael.espindola at gmail.com
Mon Nov 11 12:50:13 PST 2013


+//===-- CodeGen/RuntimeLibcalls.h - Runtime Library Calls --------*-
C++ -*-===//

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()),
+                 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
-check-prefix.

Nick, what do you think of the idea of using TargetLibraryInfo and
TargetLowering?


On 11 November 2013 12:12, Duncan Exon Smith <dexonsmith at apple.com> wrote:
> [ping]
>
> 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.
>>
>> <protect-runtime-library-functions.patch>_______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>




More information about the llvm-commits mailing list