[PATCH] D45180: libcalls must check for "RtLibUseGOT" metadata during simplification

[Sriraman Tallam via Phabricator via llvm-commits]

tmsriram added inline comments.


================
Comment at: lib/Transforms/Utils/BuildLibCalls.cpp:991
   if (File->getType()->isPointerTy())
-    inferLibFuncAttributes(*M->getFunction("fputc"), *TLI);
+    inferLibFuncAttributes(*M->getFunction("fputc"), *TLI, M);
   Char = B.CreateIntCast(Char, B.getInt32Ty(), /*isSigned*/true,
----------------
efriedma wrote:
> tmsriram wrote:
> > efriedma wrote:
> > > The "if (File->getType()->isPointerTy())" here is suspicious... I think we always need to honor the RtLibUseGOT metadata?
> > Good catch, thanks!  Looking at the other functions only the F{PutS, Putc,Write}  functions have this where it is safe to tag the param values with no capture.  When would this condition  File->getType()->isPointerTy() be false?  
> Never, I think?  At least, I can't come up with a case where it would be false; all the SimplifyLibCalls transforms should call isValidProtoForLibFunc, which should check that FILE* parameters are pointers.
> 
> That said, there is a related problem here; we don't ever check that the function returned by `M->getFunction("fputc")` has the expected signature, so this could crash if there's an existing function named fputc with the wrong signature.  (Defining a function like that has undefined behavior, so it's unlikely to come up in practice, but we still shouldn't crash.)
> Never, I think? At least, I can't come up with a case where it would be false; all the SimplifyLibCalls transforms should call isValidProtoForLibFunc, which should check that FILE* parameters are pointers.

I will leave it as it is then.  I could instead add just the  "nonlazybind" attribute here but I could create another patch that removes the condition




> That said, there is a related problem here; we don't ever check that the function returned by M->getFunction("fputc") has the expected signature, so this could crash if there's an existing function named fputc with the wrong signature. (Defining a function like that has undefined behavior, so it's unlikely to come up in practice, but we still shouldn't crash.)
> 

This probably needs to be done in a separate patch too, I see we do M->getOrInsertFunction with type and also check if the libcall is indeed there in TLI.  I see, so you want to overload fputs and that gets picked up, sigh.



https://reviews.llvm.org/D45180