Page MenuHomePhabricator

Please use GitHub pull requests for new patches. Phabricator shutdown timeline

Add llvm::llvm_fast_shutdown()

Authored by nhaehnle on Jul 5 2022, 2:15 AM.



LLD uses an unclean process exit to shut the process down faster, but
still wants the benefit of some side-effects that have traditionally
been invoked via llvm_shutdown() and ManagedStatic destruction.

The new llvm_fast_shutdown() function provides a more explicit alternative
solution that will still work when ManagedStatic is removed. Incidentally,
it also reduces the amount of cleanup code that is run even further.

This change also removes the use of ManagedStatic in the affected

Note that the StatLock is moved into the StatisticInfo class. This is a
robust solution to guarantee that the StatLock destructor doesn't run
too early.

Diff Detail

Event Timeline

nhaehnle created this revision.Jul 5 2022, 2:15 AM
Herald added a project: Restricted Project. · View Herald Transcript
nhaehnle requested review of this revision.Jul 5 2022, 2:15 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 5 2022, 2:15 AM
Herald added a subscriber: StephenFan. · View Herald Transcript

I missed something, why is ManagedStatic getting removed? Is there a discussion of this somewhere?

Context: .

The constraints here are the following:

  • Instead of relying on users calling llvm_shutdown() before unloading LLVM, we want to rely on the native __cxa_atexit or equivalent functionality.
  • We want to avoid global constructors.

The only way to completely avoid global constructors is to avoid global variables with runtime constructors or destructors. There isn't any way portable way to retrofit ManagedStatic to work the way we want. So we need to get rid of it. (In theory, I guess we could make ManagedStatic call __cxa_atexit, but it's hard to generalize that.)

nhaehnle updated this revision to Diff 447695.Jul 26 2022, 7:52 AM
  • rebase
  • add documentation to the ProgrammersManual
  • flush output streams

Do we also want to handle dumping debug counters, if that's enabled?


Do we need to worry about races accessing this boolean?


Do we need to worry about data races accessing this boolean?

efriedma added inline comments.Jul 29 2022, 1:46 PM

Looking again, maybe it's not an issue. It's only accessed in two places: the ThreadPoolExecutor constructor, and fast_shutdown_parallel(). There can't be two threads executing the ThreadPoolExecutor constructor, and fast_shutdown_parallel should not be called if there are other threads running.

Maybe worth explaining that in a comment, though.

Do we also want to handle dumping debug counters, if that's enabled?

Hmm, I think you're right. I will revisit that, also the (non-)races.

nhaehnle updated this revision to Diff 449605.Aug 3 2022, 2:31 AM
  • add some notes about data race safety
  • add the DebugCounters to the fast shutdown path
This revision is now accepted and ready to land.Aug 3 2022, 11:21 AM
MaskRay accepted this revision.Aug 4 2022, 10:18 PM
MaskRay added inline comments.

also mention -stats

MaskRay added inline comments.Aug 4 2022, 11:31 PM

To be clear, the wording should be in a way that doesn't assume -time-passes as the only exception.