Signposts.h - move unnecessary StringRef include down to Signposts.cpp

Revert "Allow signposts to take advantage of deferred string substitution"

This reverts commits f9aba9a5afe09788eceb9879aa5c3ad345e0f1e9 and
035217ff515b8ecdc871e39fa840f3cba1b9cec7.

As explained i

Revert "Allow signposts to take advantage of deferred string substitution"

This reverts commits f9aba9a5afe09788eceb9879aa5c3ad345e0f1e9 and
035217ff515b8ecdc871e39fa840f3cba1b9cec7.

As explained in the original commit message, this didn't have the
intended effect of improving the common LLDB use case, but still
provided a marginal improvement for the places where LLDB creates a
scoped time with a string literal.

The reason for the revert is that this change pulls in the os/signpost.h
header in Signposts.h. The former transitively includes loader.h, which
contains a series of macro defines that conflict with MachO.h. There are
ways to work around that, but Adrian and I concluded that none of them
are worth the trade-off in complicating Signposts.h even further.

show more ...

[llvm][clang][NFC] updates inline licence info

Some files still contained the old University of Illinois Open Source
Licence header. This patch replaces that with the Apache 2 with LLVM
Exception li

[llvm][clang][NFC] updates inline licence info

Some files still contained the old University of Illinois Open Source
Licence header. This patch replaces that with the Apache 2 with LLVM
Exception licence.

Differential Revision: https://reviews.llvm.org/D107528

show more ...

Move the definition of LLVM_SUPPORT_XCODE_SIGNPOSTS into llvm-config.h

since it is now used by a public header file (Signposts.h).
This fixes the standalone LLDB build.

Allow signposts to take advantage of deferred string substitution

One nice feature of the os_signpost API is that format string
substitutions happen in the consumer, not the logging
application. LLV

Allow signposts to take advantage of deferred string substitution

One nice feature of the os_signpost API is that format string
substitutions happen in the consumer, not the logging
application. LLVM's current Signpost class doesn't take advantage of
this though and instead always uses a static "Begin/End %s" format
string.

This patch uses variadic macros to allow the API to be used as
intended. Unfortunately, the primary use-case I had in mind (the
LLDB_SCOPED_TIMER() macro) does not get much better from this, because
__PRETTY_FUNCTION__ is *not* a macro, but a static string, so
signposts created by LLDB_SCOPED_TIMER() still use a static "%s"
format string. At least LLDB_SCOPED_TIMERF() works as intended.

This reapplies the previously reverted patch with additional include
order fixes for non-modular builds of LLDB.

Differential Revision: https://reviews.llvm.org/D103575

show more ...

Revert "Allow signposts to take advantage of deferred string substitution"

This reverts commit 03841edde7eee21d1d450041ab9a113a7e1be869.

Unfortunately this still breaks the LLDB standalone bot.

Allow signposts to take advantage of deferred string substitution

One nice feature of the os_signpost API is that format string
substitutions happen in the consumer, not the logging
application. LLV

Allow signposts to take advantage of deferred string substitution

One nice feature of the os_signpost API is that format string
substitutions happen in the consumer, not the logging
application. LLVM's current Signpost class doesn't take advantage of
this though and instead always uses a static "Begin/End %s" format
string.

This patch uses variadic macros to allow the API to be used as
intended. Unfortunately, the primary use-case I had in mind (the
LLDB_SCOPED_TIMER() macro) does not get much better from this, because
__PRETTY_FUNCTION__ is *not* a macro, but a static string, so
signposts created by LLDB_SCOPED_TIMER() still use a static "%s"
format string. At least LLDB_SCOPED_TIMERF() works as intended.

This reapplies the previsously reverted patch with additional MachO.h
macro #undefs.

Differential Revision: https://reviews.llvm.org/D103575

show more ...

Revert "Allow signposts to take advantage of deferred string substitution"

This reverts commit 4fc93a3a1f95ef5a0a57750fc621f2411ea445a8 because it
breaks LLDB builds on certain macOS platform & SDK

Revert "Allow signposts to take advantage of deferred string substitution"

This reverts commit 4fc93a3a1f95ef5a0a57750fc621f2411ea445a8 because it
breaks LLDB builds on certain macOS platform & SDK combinations, e.g.
http://green.lab.llvm.org/green/job/lldb-cmake-standalone/3288/consoleFull#-195476041949ba4694-19c4-4d7e-bec5-911270d8a58c

show more ...

Allow signposts to take advantage of deferred string substitution

One nice feature of the os_signpost API is that format string
substitutions happen in the consumer, not the logging
application. LLV

Allow signposts to take advantage of deferred string substitution

One nice feature of the os_signpost API is that format string
substitutions happen in the consumer, not the logging
application. LLVM's current Signpost class doesn't take advantage of
this though and instead always uses a static "Begin/End %s" format
string.

This patch uses variadic macros to allow the API to be used as
intended. Unfortunately, the primary use-case I had in mind (the
LLDB_SCOPED_TIMER() macro) does not get much better from this, because
__PRETTY_FUNCTION__ is *not* a macro, but a static string, so
signposts created by LLDB_SCOPED_TIMER() still use a static "%s"
format string. At least LLDB_SCOPED_TIMERF() works as intended.

This reapplies the previsously reverted patch with support for
platforms where signposts are unavailable.

Differential Revision: https://reviews.llvm.org/D103575

show more ...

Revert "Allow signposts to take advantage of deferred string substitution"

I forgot to make the LLDB macro conditional on Linux.

This reverts commit 541ccd1c1bb23e1e20a382844b35312c0caffd79.

Allow signposts to take advantage of deferred string substitution

One nice feature of the os_signpost API is that format string
substitutions happen in the consumer, not the logging
application. LLV

Allow signposts to take advantage of deferred string substitution

One nice feature of the os_signpost API is that format string
substitutions happen in the consumer, not the logging
application. LLVM's current Signpost class doesn't take advantage of
this though and instead always uses a static "Begin/End %s" format
string.

This patch uses variadic macros to allow the API to be used as
intended. Unfortunately, the primary use-case I had in mind (the
LLDB_SCOPED_TIMER() macro) does not get much better from this, because
__PRETTY_FUNCTION__ is *not* a macro, but a static string, so
signposts created by LLDB_SCOPED_TIMER() still use a static "%s"
format string. At least LLDB_SCOPED_TIMERF() works as intended.

Differential Revision: https://reviews.llvm.org/D103575

show more ...

Support: Use std::unique_ptr for SignpostEmitter::Impl, NFC, 3rd attempt

This reverts commit e35afbe535f96086141f57a5ce7d679429b4405f, reapplying
022ccedde8877e877b45e49641544b5e4fff0b42 and
e7ed5c9

Support: Use std::unique_ptr for SignpostEmitter::Impl, NFC, 3rd attempt

This reverts commit e35afbe535f96086141f57a5ce7d679429b4405f, reapplying
022ccedde8877e877b45e49641544b5e4fff0b42 and
e7ed5c920db3f537a85d962c1c918a1bb6de99fd.

- The first attempt missed defining `SignpostEmitterImpl`.
- The second attempt missed defining `llvm::SignpostEmitterImpl`.

Not sure how I failed to test both versions locally before; I thought
I'd turned the feature off via rerunning `cmake` but it must have been
stuck in place. This time I confirmed via `clang -E` that I was testing
both build configurations.

Original commit message:

Replace some manual memory management with std::unique_ptr.

Differential Revision: https://reviews.llvm.org/D100151

show more ...

Revert "Revert "Revert "Support: Use std::unique_ptr for SignpostEmitter::Impl, NFC"""

This reverts commit e7ed5c920db3f537a85d962c1c918a1bb6de99fd again, due
to more buildbot failures:
https://lab.

Revert "Revert "Revert "Support: Use std::unique_ptr for SignpostEmitter::Impl, NFC"""

This reverts commit e7ed5c920db3f537a85d962c1c918a1bb6de99fd again, due
to more buildbot failures:
https://lab.llvm.org/buildbot/#/builders/131/builds/8191

show more ...

Revert "Revert "Support: Use std::unique_ptr for SignpostEmitter::Impl, NFC""

This reverts commit 078072285d3fbdaa94f9a91140eb5c1223b548af, reapplying
022ccedde8877e877b45e49641544b5e4fff0b42.

I fi

Revert "Revert "Support: Use std::unique_ptr for SignpostEmitter::Impl, NFC""

This reverts commit 078072285d3fbdaa94f9a91140eb5c1223b548af, reapplying
022ccedde8877e877b45e49641544b5e4fff0b42.

I figured out why this was failing in other environments: it's not a
problem with std::unique_ptr, but that SignpostEmitterImpl only has a
forward declaration. Adding an empty definition should do the trick.

Original commit message:

Replace some manual memory management with std::unique_ptr.

Differential Revision: https://reviews.llvm.org/D100151

show more ...

Revert "Support: Use std::unique_ptr for SignpostEmitter::Impl, NFC"

This reverts commit 022ccedde8877e877b45e49641544b5e4fff0b42. Looks like
some hosts need a definition of SignpostEmitterImpl to p

Revert "Support: Use std::unique_ptr for SignpostEmitter::Impl, NFC"

This reverts commit 022ccedde8877e877b45e49641544b5e4fff0b42. Looks like
some hosts need a definition of SignpostEmitterImpl to put it in a
unique_ptr:
https://lab.llvm.org/buildbot/#/builders/92/builds/7733

show more ...

Support: Use std::unique_ptr for SignpostEmitter::Impl, NFC

Replace some manual memory management with std::unique_ptr.

Differential Revision: https://reviews.llvm.org/D100151

[llvm] Fix header guards (NFC)

Identified with llvm-header-guard.

[Support] Untie the llvm::Signpost interface from llvm::Timer

Make llvm::Signpost more generic by untying from llvm::Timer. This
allows signposts to be used in a different context.

My motivation fo

[Support] Untie the llvm::Signpost interface from llvm::Timer

Make llvm::Signpost more generic by untying from llvm::Timer. This
allows signposts to be used in a different context.

My motivation for doing this is being able to use signposts in LLDB.

Differential revision: https://reviews.llvm.org/D93655

show more ...

Annotate timeline in Instruments with passes and other timed regions.

Summary:
Instruments is a useful tool for finding performance issues in LLVM but it can
be difficult to identify regions of inte

Annotate timeline in Instruments with passes and other timed regions.

Summary:
Instruments is a useful tool for finding performance issues in LLVM but it can
be difficult to identify regions of interest on the timeline that we can use
to filter the profiler or allocations instrument. Xcode 10 and the latest
macOS/iOS/etc. added support for the os_signpost() API which allows us to
annotate the timeline with information that's meaningful to LLVM.

This patch causes timer start and end events to emit signposts. When used with
-time-passes, this causes the passes to be annotated on the Instruments timeline.
In addition to visually showing the duration of passes on the timeline, it also
allows us to filter the profile and allocations instrument down to an individual
pass allowing us to find the issues within that pass without being drowned out
by the noise from other parts of the compiler.

Using this in conjunction with the Time Profiler (in high frequency mode) and
the Allocations instrument is how I found the SparseBitVector that should have
been a BitVector and the DenseMap that could be replaced by a sorted vector a
couple months ago. I added NamedRegionTimers to TableGen and used the resulting
annotations to identify the slow portions of the Register Info Emitter. Some of
these were placed according to educated guesses while others were placed
according to hot functions from a previous profile. From there I filtered the
profile to a slow portion and the aforementioned issues stood out in the
profile.

To use this feature enable LLVM_SUPPORT_XCODE_SIGNPOSTS in CMake and run the
compiler under Instruments with -time-passes like so:
instruments -t 'Time Profiler' bin/llc -time-passes -o - input.ll'
Then open the resulting trace in Instruments.

There was a talk at WWDC 2018 that explained the feature which can be found at
https://developer.apple.com/videos/play/wwdc2018/405/ if you'd like to know
more about it.

Reviewers: bogner

Reviewed By: bogner

Subscribers: jdoerfert, mgorny, kristina, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D52954

llvm-svn: 354365

show more ...