search for: handlelibcall

...ilation done again with > the new objects, which could cause more bitcode files to be loaded > etc. For runtime functions defined in bitcode, we avoid the "double-LTO" scenario you describe by including them in the LTO link even if we can't prove they will be used. This is the handleLibcall code you pointed out. (https://github.com/llvm-mirror/lld/blob/master/ELF/Driver.cpp#L1733). As the comment there describes, we don't do this for runtime functions which are not defined in bitcode, to avoid other side-effects; instead we resolve those symbols after LTO. For the scenario I'...

I filed https://bugs.llvm.org/show_bug.cgi?id=42273 last night, about an inconsistency between LTO and non-LTO workflows. The basic scenario is that we have an object file which calls a function "foo", a static library that provides an implementation of "foo", and a shared library that also provides an implementation of "foo". Currently, whether lld chooses the

Hi Teresa, Thank you for the help, adding the "used" attribute worked just fine. It made me realize that the memset function is never inlined by the LTO optimization even without my implementation of the "EmitTargetCodeForMemSet" method. I supposed that the passes dealing with the memset function happen too late, is that correct? Thank you again, Romaric On Fri, Aug 28, 2020