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

Duncan Exon Smith dexonsmith at apple.com
Tue Nov 5 15:13:12 PST 2013


On Nov 5, 2013, at 1:09 PM, Rafael EspĂ­ndola <rafael.espindola at gmail.com> wrote:

>> +  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.
> 
> I don't think -fno-builtin propagates all the way here, but that is
> still a good point. We probably need a new interface for "is this a
> function llvm may produce a call to?". Good news is that that function
> can then also handle the compiler-rt symbols.

My local debugging was with a case where -fno-builtin prevented llvm.memset from being deduced, so I (wrongly) assumed -fno-builtin prevented the related intrinsics from being used at all.

-instcombine uses TargetLibraryInfo itself to check what transformations are legal in SimplifyLibraryCalls, so setting -fno-builtin will prevent transformations like printf => puts.

That leaves llvm intrinsics that mirror the C runtime (like llvm.memset and llvm.sqrt) and functions defined in compiler-rt.  These are listed by the llvm::RTLIB::Libcall enumerator, whose names are provided by TargetLowering::getLibcallName.

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.



More information about the llvm-commits mailing list