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

[Sriraman Tallam via Phabricator via llvm-commits]

tmsriram added a comment.

In https://reviews.llvm.org/D45180#1055227, @espindola wrote:

> Thinking a bit more about this:
>
> From the user perspective, the files compiled with -fno-plt should not be responsible for producing a plt. Currently we cannot represent that in the IR. To do that something like RtLibUseGOT would have to be a function attribute on the *caller*.  When llvm would decide to call a runtime function to implement llvm.foo, it would check the function using llvm.foo to find out if it should use a got or a plt.
>
> A very similar issue exists for dso_local. If a file is compiled with -fPIC and another without, a function from one but not the other could make dso_local calls to the runtime.
>
> Using these functions attributes would allow a direct mapping of what happens in the non lto case, but would be annoying to work with (what should the inliner do?).
>
> And that is just for the cases where -fno-plt is used in the command line. With a no-plt attribute it could just disappear .  Assume we have a no-plt attribute in C and someone adds it to memcpy in a translation unit. An llvm optimization can remove a memcpy that ends up being recreated during codgen and the attribute is lost. There is no good way of avoiding this.


True, cases like these are pretty hairy to deal with in general.

> The situation in here is similar, except that we don't pass an intrinsic on the way from printf to puts.
> 
> Stated that way I don't think this is that bad. It is still a quality of implementation issue as an attribute can be lost in a case where we have a chance of tracking it, but the general issue will always be there.
> 
> So I withdraw my objection as this patch at least makes things better in the common case of a -fno-plt command line option.

Awesome, thanks!


https://reviews.llvm.org/D45180