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

[Peter Collingbourne via llvm-dev]

On May 2, 2017 09:25, "Teresa Johnson" <tejohnson at google.com> wrote:



On Tue, May 2, 2017 at 8:42 AM, Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:

> +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.
>

Not a C api user, but this seems like the best option to me.



> 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.
>
>
I would prefer this option. I do not want to add any more stable API
surface to the legacy c API, and in any case this is a debugging feature so
it does not deserve stable API.

Peter

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?
>

We've talked about something like this so that we get more meaningful
timing info for ThinLTO backends which run in parallel, but haven't had the
bandwidth to address yet.

Teresa


> I have a marginal preference for 1), but does anybody have any other
> preferences or suggestions?
>
> Regards,
> James
>
>
>


-- 
Teresa Johnson |  Software Engineer |  tejohnson at google.com |  408-460-2413
<(408)%20460-2413>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170502/8087a7b7/attachment.html>