[llvm-dev] [LTO] -time-passes and libLTO

Duncan P. N. Exon Smith via llvm-dev llvm-dev at lists.llvm.org
Tue May 2 08:42:26 PDT 2017


+Teresa, Mehdi

> On May 2, 2017, at 08:31, James Henderson <jh7370.2008 at my.bristol.ac.uk> wrote:
> 
> Hi,
> 
> We have been investigating an issue when running LTO with our proprietary linker, which links against libLTO dynamically. The issue is that when we pass -time-passes via the lto_codegen_debug_options function in the LTO C API, no time information is produced during compilation. The reason for this is that time information is stored in state owned by a ManagedStatic instance, and is only printed when the state is destroyed. This in turn only happens when ManagedStatics are cleaned up, via the llvm_shutdown function. As we do not link against LLVM (except libLTO dynamically), we have no access to llvm_shutdown, which in turn means we are not able to clean up ManagedStatic instances and thus no timing information is produced.
> 
> We have considered a few options and have come up with the following suggestions, and would appreciate some feedback:
> 
> 1)      Add llvm_shutdown (or rather likely some wrapper function that does the same job) to the C interface of libLTO. This should be called when we are done with the library.
> 
This seems pretty reasonable to me.  I'm not sure what others think.
> 2)      Add a “full-shutdown” command-line option to LLVM - that can be passed via lto_codegen_debug_options - which causes ManagedStatic-owned state to be destroyed on shutdown. This could even be more widely useful outside the LTO case.
> 
> 3)      Call llvm_shutdown() immediately after compilation as part of the compile function.
> 
> 4)      None of the above, because there’s a better way that I am unaware of to clean up this state.
> 
Perhaps this timing stuff should live in the LLVMContext instead?  And then you get timing-per-LLVMContext?
> I have a marginal preference for 1), but does anybody have any other preferences or suggestions?
> 
> Regards,
> 
> James

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170502/4712ae20/attachment.html>


More information about the llvm-dev mailing list