History log of /llvm-project/llvm/lib/Support/Timer.cpp (Results 1 – 25 of 169)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init, llvmorg-19.1.7
# 24bd9bc0 11-Jan-2025 Fangrui Song <i@maskray.me>

[Timer] Remove signpots overhead on unsupported systems

startTimer/stopTimer are frequently called. It's important to reduce
overhead.


# 0de18e72 11-Jan-2025 Fangrui Song <i@maskray.me>

-ftime-report: reorganize timers

The code generation time is unclear in the -ftime-report output:

* The two clang timers "Code Generation Time" and "LLVM IR Generation
Time" are in the default gr

-ftime-report: reorganize timers

The code generation time is unclear in the -ftime-report output:

* The two clang timers "Code Generation Time" and "LLVM IR Generation
Time" are in the default group "Miscellaneous Ungrouped Timers".
* There is also a "Clang front-end time" group, which actually includes
code generation time.

```
===-------------------------------------------------------------------------===
Miscellaneous Ungrouped Timers
===-------------------------------------------------------------------------===

---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name ---
0.0611 ( 1.7%) 0.0099 ( 4.4%) 0.0710 ( 1.9%) 0.0713 ( 1.9%) LLVM IR Generation Time
3.5140 ( 98.3%) 0.2165 ( 95.6%) 3.7306 ( 98.1%) 3.7342 ( 98.1%) Code Generation Time
3.5751 (100.0%) 0.2265 (100.0%) 3.8016 (100.0%) 3.8055 (100.0%) Total
...
===-------------------------------------------------------------------------===
Clang front-end time report
===-------------------------------------------------------------------------===
Total Execution Time: 3.9108 seconds (3.9146 wall clock)

---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name ---
3.6802 (100.0%) 0.2306 (100.0%) 3.9108 (100.0%) 3.9146 (100.0%) Clang front-end timer
3.6802 (100.0%) 0.2306 (100.0%) 3.9108 (100.0%) 3.9146 (100.0%) Total
```

This patch

* renames "Clang front-end time report" (FrontendAction time) to "Clang
time report",
* renames "Clang front-end" to "Front end",
* moves "LLVM IR Generation" into the group,
* replaces "Code Generation time" with "Optimizer" (middle end) and
"Machine code generation" (back end).

```
% clang -c sqlite3.i -w -ftime-report -mllvm -sort-timers=0
...
===-------------------------------------------------------------------------===
Clang time report
===-------------------------------------------------------------------------===
Total Execution Time: 1.5922 seconds (1.5972 wall clock)

---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name ---
0.5107 ( 35.9%) 0.0105 ( 6.2%) 0.5211 ( 32.7%) 0.5222 ( 32.7%) Front end
0.2464 ( 17.3%) 0.0340 ( 20.0%) 0.2804 ( 17.6%) 0.2814 ( 17.6%) LLVM IR generation
0.6240 ( 43.9%) 0.1235 ( 72.7%) 0.7475 ( 47.0%) 0.7503 ( 47.0%) Machine code generation
0.0413 ( 2.9%) 0.0018 ( 1.0%) 0.0431 ( 2.7%) 0.0433 ( 2.7%) Optimizer
1.4224 (100.0%) 0.1698 (100.0%) 1.5922 (100.0%) 1.5972 (100.0%) Total
```

Pull Request: https://github.com/llvm/llvm-project/pull/122225

show more ...


# af4d76d9 11-Jan-2025 Fangrui Song <i@maskray.me>

[Support] Reduce globaal variable overhead after #121663

* Construct frequently-accessed TimerLock/DefaultTimerGroup early to
reduce overhead.
* Rename `aquireDefaultGroup` to `acquireTimerGlobals

[Support] Reduce globaal variable overhead after #121663

* Construct frequently-accessed TimerLock/DefaultTimerGroup early to
reduce overhead.
* Rename `aquireDefaultGroup` to `acquireTimerGlobals` and restore
ManagedStatic::claim. https://reviews.llvm.org/D76099

* Drop mtg::. We use internal linkage, so mtg:: is unneeded and might
mislead users. In addition, llvm/ code almost never introduces a named
namespace not in llvm::. Drop mtg::.
* Replace some unique_ptr with optional to reduce overhead.
* Switch to `functionName()`.
* Simplify `llvm::initTimerOptions` and `TimerGroup::constructForStatistics()`

Pull Request: https://github.com/llvm/llvm-project/pull/122429

show more ...


# 8ac6a6b8 09-Jan-2025 Benjamin Kramer <benny.kra@googlemail.com>

Reorder fields so InitDeferredFlag is destroyed last

TimerGroup's dtor accesses this field.

once_flag has a trivial destructor so it doesn't really matter, but msan
checks that it's not accessed af

Reorder fields so InitDeferredFlag is destroyed last

TimerGroup's dtor accesses this field.

once_flag has a trivial destructor so it doesn't really matter, but msan
checks that it's not accessed after destruction.

show more ...


# e3e26dc4 09-Jan-2025 Jie Fu <jiefu@tencent.com>

[llvm] Remove extra ';' outside of a function (NFC)

/llvm-project/llvm/lib/Support/Timer.cpp:565:74:
error: extra ';' outside of a function is incompatible with C++98 [-Werror,-Wc++98-compat-extra-s

[llvm] Remove extra ';' outside of a function (NFC)

/llvm-project/llvm/lib/Support/Timer.cpp:565:74:
error: extra ';' outside of a function is incompatible with C++98 [-Werror,-Wc++98-compat-extra-semi]
static bool mtg::TrackSpace() { return ManagedTimerGlobals->TrackSpace; };
^
1 error generated.

show more ...


# 52c338da 09-Jan-2025 macurtis-amd <macurtis@amd.com>

[llvm][NFC] Rework Timer.cpp globals to ensure valid lifetimes (#121663)

This is intended to help with flang `-ftime-report` support:
- #107270.

With this change, I was able to cherry-pick #1072

[llvm][NFC] Rework Timer.cpp globals to ensure valid lifetimes (#121663)

This is intended to help with flang `-ftime-report` support:
- #107270.

With this change, I was able to cherry-pick #107270, uncomment
`llvm::TimePassesIsEnabled = true;` and compile with `-ftime-report`.

I also noticed that `clang/lib/Driver/OffloadBundler.cpp` was statically
constructing a `TimerGroup` and changed it to lazily construct via
ManagedStatic.

show more ...


Revision tags: llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4
# 5b356f27 31-Oct-2024 Daniel Sanders <daniel_l_sanders@apple.com>

Trivial change llvm::CreateInfoOutputFile() to return raw_ostream. NFC

This is NFC w.r.t upstream but allows us to return raw_null_ostream in our
downstream fork without changing the interface.


Revision tags: llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2
# af2e5499 03-Aug-2022 Nicolai Hähnle <nicolai.haehnle@amd.com>

[Timer][Statistics] Make global constructor ordering more robust

It was observed in D129117 that the subtle dependency between statistic
and timer code is not entirely robust: the global destructor

[Timer][Statistics] Make global constructor ordering more robust

It was observed in D129117 that the subtle dependency between statistic
and timer code is not entirely robust: the global destructor
~StatisticInfo indirectly calls CreateInfoOutputFile, which requires
the LibSupportInfoOutputFilename to not have been destructed.

By constructing LibSupportInfoOutputFilename before the StatisticInfo
object, the order of destruction is guaranteed.

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

show more ...


Revision tags: llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1
# 843d1eda 07-Nov-2021 Kazu Hirata <kazu@google.com>

[llvm] Use llvm::reverse (NFC)


# 070315d0 11-Oct-2021 Jonas Devlieghere <jonas@devlieghere.com>

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


Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init
# 76374573 15-Jul-2021 Mehdi Amini <joker.eph@gmail.com>

Use ManagedStatic and lazy initialization of cl::opt in libSupport to make it free of global initializer

We can build it with -Werror=global-constructors now. This helps
in situation where libSuppor

Use ManagedStatic and lazy initialization of cl::opt in libSupport to make it free of global initializer

We can build it with -Werror=global-constructors now. This helps
in situation where libSupport is embedded as a shared library,
potential with dlopen/dlclose scenario, and when command-line
parsing or other facilities may not be involved. Avoiding the
implicit construction of these cl::opt can avoid double-registration
issues and other kind of behavior.

Reviewed By: lattner, jpienaar

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

show more ...


# 8d051d85 16-Jul-2021 Mehdi Amini <joker.eph@gmail.com>

Revert "Use ManagedStatic and lazy initialization of cl::opt in libSupport to make it free of global initializer"

This reverts commit af9321739b20becf170e6bb5060b8d780e1dc8dd.
Still some specific co

Revert "Use ManagedStatic and lazy initialization of cl::opt in libSupport to make it free of global initializer"

This reverts commit af9321739b20becf170e6bb5060b8d780e1dc8dd.
Still some specific config broken in some way that requires more
investigation.

show more ...


# af932173 15-Jul-2021 Mehdi Amini <joker.eph@gmail.com>

Use ManagedStatic and lazy initialization of cl::opt in libSupport to make it free of global initializer

We can build it with -Werror=global-constructors now. This helps
in situation where libSuppor

Use ManagedStatic and lazy initialization of cl::opt in libSupport to make it free of global initializer

We can build it with -Werror=global-constructors now. This helps
in situation where libSupport is embedded as a shared library,
potential with dlopen/dlclose scenario, and when command-line
parsing or other facilities may not be involved. Avoiding the
implicit construction of these cl::opt can avoid double-registration
issues and other kind of behavior.

Reviewed By: lattner, jpienaar

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

show more ...


# 16b5e9d6 16-Jul-2021 Mehdi Amini <joker.eph@gmail.com>

Revert "Use ManagedStatic and lazy initialization of cl::opt in libSupport to make it free of global initializer"

This reverts commit 42f588f39c5ce6f521e3709b8871d1fdd076292f.
Broke some buildbots


# 42f588f3 15-Jul-2021 Mehdi Amini <joker.eph@gmail.com>

Use ManagedStatic and lazy initialization of cl::opt in libSupport to make it free of global initializer

We can build it with -Werror=global-constructors now. This helps
in situation where libSuppor

Use ManagedStatic and lazy initialization of cl::opt in libSupport to make it free of global initializer

We can build it with -Werror=global-constructors now. This helps
in situation where libSupport is embedded as a shared library,
potential with dlopen/dlclose scenario, and when command-line
parsing or other facilities may not be involved. Avoiding the
implicit construction of these cl::opt can avoid double-registration
issues and other kind of behavior.

Reviewed By: lattner, jpienaar

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

show more ...


Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2
# 035217ff 11-Jun-2021 Adrian Prantl <aprantl@apple.com>

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


# 7a7c0076 14-Jun-2021 Adrian Prantl <aprantl@apple.com>

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

This reverts commit 03841edde7eee21d1d450041ab9a113a7e1be869.

Unfortunately this still breaks the LLDB standalone bot.


# 03841edd 11-Jun-2021 Adrian Prantl <aprantl@apple.com>

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


# b4583a5a 12-Jun-2021 Florian Hahn <flo@fhahn.com>

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


# 4fc93a3a 11-Jun-2021 Adrian Prantl <aprantl@apple.com>

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


# b90f9bea 11-Jun-2021 Adrian Prantl <aprantl@apple.com>

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

I forgot to make the LLDB macro conditional on Linux.

This reverts commit 541ccd1c1bb23e1e20a382844b35312c0caffd79.


# 541ccd1c 11-Jun-2021 Adrian Prantl <aprantl@apple.com>

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


Revision tags: llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5
# 82b3e28e 06-Apr-2021 Abhina Sreeskantharajan <Abhina.Sreeskantharajan@ibm.com>

[SystemZ][z/OS][Windows] Add new OF_TextWithCRLF flag and use this flag instead of OF_Text

Problem:
On SystemZ we need to open text files in text mode. On Windows, files opened in text mode adds a C

[SystemZ][z/OS][Windows] Add new OF_TextWithCRLF flag and use this flag instead of OF_Text

Problem:
On SystemZ we need to open text files in text mode. On Windows, files opened in text mode adds a CRLF '\r\n' which may not be desirable.

Solution:
This patch adds two new flags

- OF_CRLF which indicates that CRLF translation is used.
- OF_TextWithCRLF = OF_Text | OF_CRLF indicates that the file is text and uses CRLF translation.

Developers should now use either the OF_Text or OF_TextWithCRLF for text files and OF_None for binary files. If the developer doesn't want carriage returns on Windows, they should use OF_Text, if they do want carriage returns on Windows, they should use OF_TextWithCRLF.

So this is the behaviour per platform with my patch:

z/OS:
OF_None: open in binary mode
OF_Text : open in text mode
OF_TextWithCRLF: open in text mode

Windows:
OF_None: open file with no carriage return
OF_Text: open file with no carriage return
OF_TextWithCRLF: open file with carriage return

The Major change is in llvm/lib/Support/Windows/Path.inc to only set text mode if the OF_CRLF is set.
```
if (Flags & OF_CRLF)
CrtOpenFlags |= _O_TEXT;
```

These following files are the ones that still use OF_Text which I left unchanged. I modified all these except raw_ostream.cpp in recent patches so I know these were previously in Binary mode on Windows.
./llvm/lib/Support/raw_ostream.cpp
./llvm/lib/TableGen/Main.cpp
./llvm/tools/dsymutil/DwarfLinkerForBinary.cpp
./llvm/unittests/Support/Path.cpp
./clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
./clang/lib/Frontend/CompilerInstance.cpp
./clang/lib/Driver/Driver.cpp
./clang/lib/Driver/ToolChains/Clang.cpp

Reviewed By: MaskRay

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

show more ...


Revision tags: llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2
# 7e3b9aba 11-Feb-2021 Alex Hoppen <alex@alexhoppen.de>

[Timer] On macOS count number of executed instructions

In addition to wall time etc. this should allow us to get less noisy
values for time measurements.

Reviewed By: JDevlieghere

Differential Rev

[Timer] On macOS count number of executed instructions

In addition to wall time etc. this should allow us to get less noisy
values for time measurements.

Reviewed By: JDevlieghere

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

show more ...


Revision tags: llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1
# b37de2af 06-Jan-2021 Jonas Devlieghere <jonas@devlieghere.com>

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


1234567