[PATCH] D49434: Put "built-in" function definitions in global Used list, for LTO. (fix bug 34169)

Steven Wu via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jul 20 13:46:08 PDT 2018


steven_wu added a comment.

In https://reviews.llvm.org/D49434#1170267, @pcc wrote:

> I would imagine that folks who care about code size would be linking with `--gc-sections` (or `-dead_strip` in ld64) so the library functions would end up being dropped if they aren't actually needed.


This is true.

> This also sounds pretty fragile (not just LTO, but in general). If you have a module with implementation of memcpy and all you have is memcpy builtin function, DCE might just cause linker failure. I wonder the problem should be solved in a lower level.

Now I think again, it seems this is LTO specific because I can't think of any other condition that those function can be internal.

In https://reviews.llvm.org/D49434#1170267, @pcc wrote:

> In https://reviews.llvm.org/D49434#1170189, @steven_wu wrote:
>
> > For the old API, I don't think it is reasonable to expect user or linker to pass in the correct preserve list. There is likely no knowledge outside the LTO modules that these lib funcs are needed.
>
>
> I was under the impression that that was how things worked already on Apple platforms but given that it isn't, I agree.


No, it doesn't work. I think it just happens that regularLTO from old API doesn't actually drop them. I think it would be better to update the Internalize pass used by regularLTO C API to not internalize those function to be safe (it already has an exception for stack protector symbols) just in case. The thinLTO C API shouldn't be that hard to fix as well. I am ok to fix them with a separate commits.


https://reviews.llvm.org/D49434





More information about the llvm-commits mailing list