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