Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6 |
|
#
dd647e3e |
| 11-Dec-2024 |
Chandler Carruth <chandlerc@gmail.com> |
Rework the `Option` library to reduce dynamic relocations (#119198)
Apologies for the large change, I looked for ways to break this up and
all of the ones I saw added real complexity. This change f
Rework the `Option` library to reduce dynamic relocations (#119198)
Apologies for the large change, I looked for ways to break this up and
all of the ones I saw added real complexity. This change focuses on the
option's prefixed names and the array of prefixes. These are present in
every option and the dominant source of dynamic relocations for PIE or
PIC users of LLVM and Clang tooling. In some cases, 100s or 1000s of
them for the Clang driver which has a huge number of options.
This PR addresses this by building a string table and a prefixes table
that can be referenced with indices rather than pointers that require
dynamic relocations. This removes almost 7k dynmaic relocations from the
`clang` binary, roughly 8% of the remaining dynmaic relocations outside
of vtables. For busy-boxing use cases where many different option tables
are linked into the same binary, the savings add up a bit more.
The string table is a straightforward mechanism, but the prefixes
required some subtlety. They are encoded in a Pascal-string fashion with
a size followed by a sequence of offsets. This works relatively well for
the small realistic prefixes arrays in use.
Lots of code has to change in order to land this though: both all the
option library code has to be updated to use the string table and
prefixes table, and all the users of the options library have to be
updated to correctly instantiate the objects.
Some follow-up patches in the works to provide an abstraction for this
style of code, and to start using the same technique for some of the
other strings here now that the infrastructure is in place.
show more ...
|
Revision tags: llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3 |
|
#
d582442b |
| 21-Oct-2024 |
Ronan Keryell <ronan.keryell@amd.com> |
[llvm-cxxfilt] Add --quote option to quote demangled function names (#111871)
This is useful when looking at LLVM/MLIR assembly produced from C++
sources. For example
cir.call @_ZN3aie4tileILi1EL
[llvm-cxxfilt] Add --quote option to quote demangled function names (#111871)
This is useful when looking at LLVM/MLIR assembly produced from C++
sources. For example
cir.call @_ZN3aie4tileILi1ELi4EE7programIZ4mainE3$_0EEvOT_(%2, %7) :
will be translated to
cir.call @"void aie::tile<1, 4>::program<main::$_0>(main::$_0&&)"(%2,
%7) : which can be parsed as valid MLIR by the right mlir-lsp-server.
If a symbol is already quoted, do not quote it more.
---------
Co-authored-by: James Henderson <jh7370@my.bristol.ac.uk>
show more ...
|
Revision tags: llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4 |
|
#
0b554dd9 |
| 28-Aug-2024 |
Michael Buch <michaelbuch12@gmail.com> |
[llvm-cxxfilt][macOS] Don't strip underscores on macOS by default (#106233)
Currently, `llvm-cxxfilt` will strip the leading underscore of its input
on macOS. Historically MachO symbols were prefix
[llvm-cxxfilt][macOS] Don't strip underscores on macOS by default (#106233)
Currently, `llvm-cxxfilt` will strip the leading underscore of its input
on macOS. Historically MachO symbols were prefixed with an extra
underscore and this is why this default exists. However, nowadays, the
`ItaniumDemangler` supports all of the following mangling prefixes:
`_Z`, `__Z`, `___Z`, `____Z`. So really `llvm-cxxfilt` can simply
forward the mangled name to the demangler and let the library decide
whether it's a valid encoding.
Compiling C++ on macOS nowadays will generate symbols with `_Z` and
`___Z` prefixes. So users trying to demangle these symbols will have to
know that they need to add the `-n` prefix. This routinely catches
people off-guard.
This patch removes the `-n` default for macOS and allows calling into
the `ItaniumDemangler` with all the `_Z` prefixes that the demangler
supports (1-4 underscores).
rdar://132714940
show more ...
|
Revision tags: 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 |
|
#
3c6f47d6 |
| 12-Jan-2024 |
Alexandre Ganea <37383324+aganea@users.noreply.github.com> |
[llvm-driver] Fix usage of `InitLLVM` on Windows (#76306)
Previously, some tools such as `clang` or `lld` which require strict
order for certain command-line options, such as `clang -cc1` or `lld
[llvm-driver] Fix usage of `InitLLVM` on Windows (#76306)
Previously, some tools such as `clang` or `lld` which require strict
order for certain command-line options, such as `clang -cc1` or `lld
-flavor`, would not longer work on Windows, when these tools were linked
as part of `llvm-driver`. This was caused by `InitLLVM` which was part
of the `*_main()` function of these tools, which in turn calls
`windows::GetCommandLineArguments`. That function completly replaces
argc/argv by new UTF-8 contents, so any ajustements to argc/argv made by
`llvm-driver` prior to calling these tools was reset.
`InitLLVM` is now called by the `llvm-driver`. Any tool that
participates in (or is part of) the `llvm-driver` doesn't call
`InitLLVM` anymore.
show more ...
|
#
569ec185 |
| 04-Jan-2024 |
Dmitry Vasilyev <dvassiliev@accesssoftek.com> |
[llvm-cxxfilt] Added the option --no-params (#75348)
Added -p / --no-params flag to skip demangling function parameters similar to how it is supported by GNU c++filt tool.
There are cases when user
[llvm-cxxfilt] Added the option --no-params (#75348)
Added -p / --no-params flag to skip demangling function parameters similar to how it is supported by GNU c++filt tool.
There are cases when users want to demangle a large number of symbols in bulk, for example, at startup, and do not care about function parameters and overloads at that time. Skipping the demangling of parameter types led to a measurable improvement in performance. Our users reported about 15% speed up with GNU c++filt and we expect similar results with llvm-cxxfilt with this patch.
show more ...
|
#
c91fab50 |
| 02-Jan-2024 |
Arthur Eubanks <aeubanks@google.com> |
Revert "[llvm-cxxfilt] Added the option --no-params (#75348)"
This reverts commit 71f8ea3062a6b0a190835853ee77e58469763b9e.
Test doesn't pass on mac. See comments on https://github.com/llvm/llvm-pr
Revert "[llvm-cxxfilt] Added the option --no-params (#75348)"
This reverts commit 71f8ea3062a6b0a190835853ee77e58469763b9e.
Test doesn't pass on mac. See comments on https://github.com/llvm/llvm-project/pull/75348.
show more ...
|
#
71f8ea30 |
| 02-Jan-2024 |
Dmitry Vasilyev <dvassiliev@accesssoftek.com> |
[llvm-cxxfilt] Added the option --no-params (#75348)
Added -p / --no-params flag to skip demangling function parameters
similar to how it is supported by GNU c++filt tool.
There are cases when u
[llvm-cxxfilt] Added the option --no-params (#75348)
Added -p / --no-params flag to skip demangling function parameters
similar to how it is supported by GNU c++filt tool.
There are cases when users want to demangle a large number of symbols in
bulk, for example, at startup, and do not care about function parameters
and overloads at that time. Skipping the demangling of parameter types
led to a measurable improvement in performance. Our users reported about
15% speed up with GNU c++filt and we expect similar results with
llvm-cxxfilt with this patch.
show more ...
|
Revision tags: llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2 |
|
#
1ff958c3 |
| 26-Sep-2023 |
zhijian <zhijian@ca.ibm.com> |
[llvm-cxxfilt] Do not consider the prefix dot as part of the demangled symbol name.
Summary:
In AIX OS, function entry label are begin with '.', it can not be decoded currently. we support to decod
[llvm-cxxfilt] Do not consider the prefix dot as part of the demangled symbol name.
Summary:
In AIX OS, function entry label are begin with '.', it can not be decoded currently. we support to decode the name in this patch for all OS.
Reviewers: Fangrui Song, James Henderson, Differential Revision: https://reviews.llvm.org/D139864
show more ...
|
Revision tags: llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3 |
|
#
dcb6d212 |
| 14-Aug-2023 |
Justin Bogner <mail@justinbogner.com> |
Reapply "[Option] Add "Visibility" field and clone the OptTable APIs to use it"
This reverts commit 4e3b89483a6922d3f48670bb1c50a37f342918c6, with fixes for places I'd missed updating in lld and lld
Reapply "[Option] Add "Visibility" field and clone the OptTable APIs to use it"
This reverts commit 4e3b89483a6922d3f48670bb1c50a37f342918c6, with fixes for places I'd missed updating in lld and lldb. I've also renamed OptionVisibility::Default to "DefaultVis" to avoid ambiguity since the undecorated name has to be available anywhere Options.inc is included.
Original message follows:
This splits OptTable's "Flags" field into "Flags" and "Visibility", updates the places where we instantiate Option tables, and adds variants of the OptTable APIs that use Visibility mask instead of Include/Exclude flags.
We need to do this to clean up a bunch of complexity in the clang driver's option handling - there's a whole slew of flags like CoreOption, NoDriverOption, and FlangOnlyOption there today to try to handle all of the permutations of flags that the various drivers need, but it really doesn't scale well, as can be seen by things like the somewhat recently introduced CLDXCOption.
Instead, we'll provide an additive model for visibility that's separate from the other flags. For things like "HelpHidden", which is used as a "subtractive" modifier for option visibility, we leave that in "Flags" and handle it as a special case.
Note that we don't actually update the users of the Include/Exclude APIs here or change the flags that exist in clang at all - that will come in a follow up that refactors clang's Options.td to use the increased flexibility this change allows.
Differential Revision: https://reviews.llvm.org/D157149
show more ...
|
#
4e3b8948 |
| 14-Aug-2023 |
Justin Bogner <mail@justinbogner.com> |
Revert "[Option] Add "Visibility" field and clone the OptTable APIs to use it"
this is failing on bots, reverting to investigate.
This reverts commit a16104e6da6f36f3d72dbf53d10ba56495a0d65a.
|
Revision tags: llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init |
|
#
a16104e6 |
| 21-Jul-2023 |
Justin Bogner <mail@justinbogner.com> |
[Option] Add "Visibility" field and clone the OptTable APIs to use it
This splits OptTable's "Flags" field into "Flags" and "Visibility", updates the places where we instantiate Option tables, and a
[Option] Add "Visibility" field and clone the OptTable APIs to use it
This splits OptTable's "Flags" field into "Flags" and "Visibility", updates the places where we instantiate Option tables, and adds variants of the OptTable APIs that use Visibility mask instead of Include/Exclude flags.
We need to do this to clean up a bunch of complexity in the clang driver's option handling - there's a whole slew of flags like CoreOption, NoDriverOption, and FlangOnlyOption there today to try to handle all of the permutations of flags that the various drivers need, but it really doesn't scale well, as can be seen by things like the somewhat recently introduced CLDXCOption.
Instead, we'll provide an additive model for visibility that's separate from the other flags. For things like "HelpHidden", which is used as a "subtractive" modifier for option visibility, we leave that in "Flags" and handle it as a special case.
Note that we don't actually update the users of the Include/Exclude APIs here or change the flags that exist in clang at all - that will come in a follow up that refactors clang's Options.td to use the increased flexibility this change allows.
Differential Revision: https://reviews.llvm.org/D157149
show more ...
|
#
3f092f37 |
| 04-Aug-2023 |
Jan Svoboda <jan_svoboda@apple.com> |
[llvm] Extract common `OptTable` bits into macros
All command-line tools using `llvm::opt` create an enum of option IDs and a table of `OptTable::Info` object. Most of the tools use the same ID (`OP
[llvm] Extract common `OptTable` bits into macros
All command-line tools using `llvm::opt` create an enum of option IDs and a table of `OptTable::Info` object. Most of the tools use the same ID (`OPT_##ID`), kind (`Option::KIND##Class`), group ID (`OPT_##GROUP`) and alias ID (`OPT_##ALIAS`). This patch extracts that common code into canonical macros. This results in fewer changes when tweaking the `OPTION` macros emitted by the TableGen backend.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D157028
show more ...
|
Revision tags: llvmorg-16.0.6 |
|
#
61e1c3d8 |
| 02-Jun-2023 |
Nick Desaulniers <ndesaulniers@google.com> |
[Demangle] convert itaniumDemangle and nonMicrosoftDemangle to use std::string_view
D149104 converted llvm::demangle to use std::string_view. Enabling "expensive checks" (via -DLLVM_ENABLE_EXPENSIVE
[Demangle] convert itaniumDemangle and nonMicrosoftDemangle to use std::string_view
D149104 converted llvm::demangle to use std::string_view. Enabling "expensive checks" (via -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON) causes lld/test/wasm/why-extract.s to fail. The reason for this is obscure:
Reason #10007 why std::string_view is dangerous: Consider the following pattern:
std::string_view s = ...; const char *c = s.data(); std::strlen(c);
Is c a NUL-terminated C style string? It depends; but if it's not then it's not safe to call std::strlen on the std::string_view::data(). std::string_view::length() should be used instead.
Fixing this fixes the one lone test that caught this.
microsoftDemangle, rustDemangle, and dlangDemangle should get this same treatment, too. I will do that next.
Reviewed By: MaskRay, efriedma
Differential Revision: https://reviews.llvm.org/D149675
show more ...
|
Revision tags: llvmorg-16.0.5, llvmorg-16.0.4 |
|
#
3b01fa26 |
| 03-May-2023 |
Nick Desaulniers <ndesaulniers@google.com> |
[Demangle] remove unused status param of itaniumDemangle
No call sites interpreted this value meaningfully. Simplify this interface.
Reviewed By: MaskRay
Differential Revision: https://reviews.llv
[Demangle] remove unused status param of itaniumDemangle
No call sites interpreted this value meaningfully. Simplify this interface.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D149707
show more ...
|
#
7277a72b |
| 03-May-2023 |
Nick Desaulniers <ndesaulniers@google.com> |
[Demangle] remove unused params of itaniumDemangle
No call sites use these parameters, so drop them. Equivalent to D148940.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D14
[Demangle] remove unused params of itaniumDemangle
No call sites use these parameters, so drop them. Equivalent to D148940.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D149703
show more ...
|
Revision tags: 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 |
|
#
1f173a06 |
| 10-Feb-2023 |
Alex Brachet <abrachet@google.com> |
[llvm-driver] Pass extra arguments to tools
Differential Revision: https://reviews.llvm.org/D137799
|
#
d768bf99 |
| 10-Feb-2023 |
Archibald Elliott <archibald.elliott@arm.com> |
[NFC][TargetParser] Replace uses of llvm/Support/Host.h
The forwarding header is left in place because of its use in `polly/lib/External/isl/interface/extract_interface.cc`, but I have added a GCC w
[NFC][TargetParser] Replace uses of llvm/Support/Host.h
The forwarding header is left in place because of its use in `polly/lib/External/isl/interface/extract_interface.cc`, but I have added a GCC warning about the fact it is deprecated, because it is used in `isl` from where it is included by Polly.
show more ...
|
Revision tags: llvmorg-16.0.0-rc2 |
|
#
62c7f035 |
| 07-Feb-2023 |
Archibald Elliott <archibald.elliott@arm.com> |
[NFC][TargetParser] Remove llvm/ADT/Triple.h
I also ran `git clang-format` to get the headers in the right order for the new location, which has changed the order of other headers in two files.
|
Revision tags: llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7 |
|
#
07bb29d8 |
| 30-Dec-2022 |
serge-sans-paille <sguelton@mozilla.com> |
[OptTable] Precompute OptTable prefixes union table through tablegen
This avoid rediscovering this table when reading each options, providing a sensible 2% speedup when processing and empty file, an
[OptTable] Precompute OptTable prefixes union table through tablegen
This avoid rediscovering this table when reading each options, providing a sensible 2% speedup when processing and empty file, and a measurable speedup on typical workloads, see:
This is optional, the legacy, on-the-fly, approach can still be used through the GenericOptTable class, while the new one is used through PrecomputedOptTable.
https://llvm-compile-time-tracker.com/compare.php?from=4da6cb3202817ee2897d6b690e4af950459caea4&to=19a492b704e8f5c1dea120b9c0d3859bd78796be&stat=instructions:u
Differential Revision: https://reviews.llvm.org/D140800
show more ...
|
#
d9ab3e82 |
| 26-Dec-2022 |
serge-sans-paille <sguelton@mozilla.com> |
[clang] Use a StringRef instead of a raw char pointer to store builtin and call information
This avoids recomputing string length that is already known at compile time.
It has a slight impact on pr
[clang] Use a StringRef instead of a raw char pointer to store builtin and call information
This avoids recomputing string length that is already known at compile time.
It has a slight impact on preprocessing / compile time, see
https://llvm-compile-time-tracker.com/compare.php?from=3f36d2d579d8b0e8824d9dd99bfa79f456858f88&to=e49640c507ddc6615b5e503144301c8e41f8f434&stat=instructions:u
This a recommit of e953ae5bbc313fd0cc980ce021d487e5b5199ea4 and the subsequent fixes caa713559bd38f337d7d35de35686775e8fb5175 and 06b90e2e9c991e211fecc97948e533320a825470.
The above patchset caused some version of GCC to take eons to compile clang/lib/Basic/Targets/AArch64.cpp, as spotted in aa171833ab0017d9732e82b8682c9848ab25ff9e. The fix is to make BuiltinInfo tables a compilation unit static variable, instead of a private static variable.
Differential Revision: https://reviews.llvm.org/D139881
show more ...
|
#
aa171833 |
| 26-Dec-2022 |
Vitaly Buka <vitalybuka@google.com> |
Revert "[clang] Use a StringRef instead of a raw char pointer to store builtin and call information" Revert "Fix lldb option handling since e953ae5bbc313fd0cc980ce021d487e5b5199ea4 (part 2)" Revert "
Revert "[clang] Use a StringRef instead of a raw char pointer to store builtin and call information" Revert "Fix lldb option handling since e953ae5bbc313fd0cc980ce021d487e5b5199ea4 (part 2)" Revert "Fix lldb option handling since e953ae5bbc313fd0cc980ce021d487e5b5199ea4"
GCC build hangs on this bot https://lab.llvm.org/buildbot/#/builders/37/builds/19104 compiling CMakeFiles/obj.clangBasic.dir/Targets/AArch64.cpp.d
The bot uses GNU 11.3.0, but I can reproduce locally with gcc (Debian 12.2.0-3) 12.2.0.
This reverts commit caa713559bd38f337d7d35de35686775e8fb5175. This reverts commit 06b90e2e9c991e211fecc97948e533320a825470. This reverts commit e953ae5bbc313fd0cc980ce021d487e5b5199ea4.
show more ...
|
#
e953ae5b |
| 12-Dec-2022 |
serge-sans-paille <sguelton@mozilla.com> |
[clang] Use a StringRef instead of a raw char pointer to store builtin and call information
This avoids recomputing string length that is already known at compile time.
It has a slight impact on pr
[clang] Use a StringRef instead of a raw char pointer to store builtin and call information
This avoids recomputing string length that is already known at compile time.
It has a slight impact on preprocessing / compile time, see
https://llvm-compile-time-tracker.com/compare.php?from=3f36d2d579d8b0e8824d9dd99bfa79f456858f88&to=e49640c507ddc6615b5e503144301c8e41f8f434&stat=instructions:u
This is a recommit of 719d98dfa841c522d8d452f0685e503538415a53 that into account a GGC issue (probably https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92181) when dealing with intiailizer_list and constant expressions.
Workaround this by avoiding initializer list, at the expense of a temporary plain old array.
Differential Revision: https://reviews.llvm.org/D139881
show more ...
|
#
07d9ab9a |
| 23-Dec-2022 |
serge-sans-paille <sguelton@mozilla.com> |
Revert "[clang] Use a StringRef instead of a raw char pointer to store builtin and call information"
There are still remaining issues with GCC 12, see for instance
https://lab.llvm.org/buildbot/#/b
Revert "[clang] Use a StringRef instead of a raw char pointer to store builtin and call information"
There are still remaining issues with GCC 12, see for instance
https://lab.llvm.org/buildbot/#/builders/93/builds/12669
This reverts commit 5ce4e92264102de21760c94db9166afe8f71fcf6.
show more ...
|
#
5ce4e922 |
| 12-Dec-2022 |
serge-sans-paille <sguelton@mozilla.com> |
[clang] Use a StringRef instead of a raw char pointer to store builtin and call information
This avoids recomputing string length that is already known at compile time.
It has a slight impact on pr
[clang] Use a StringRef instead of a raw char pointer to store builtin and call information
This avoids recomputing string length that is already known at compile time.
It has a slight impact on preprocessing / compile time, see
https://llvm-compile-time-tracker.com/compare.php?from=3f36d2d579d8b0e8824d9dd99bfa79f456858f88&to=e49640c507ddc6615b5e503144301c8e41f8f434&stat=instructions:u
This is a recommit of 719d98dfa841c522d8d452f0685e503538415a53 with a change to llvm/utils/TableGen/OptParserEmitter.cpp to cope with GCC bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108158
Differential Revision: https://reviews.llvm.org/D139881
show more ...
|
#
b7065a31 |
| 23-Dec-2022 |
serge-sans-paille <sguelton@mozilla.com> |
Revert "[clang] Use a StringRef instead of a raw char pointer to store builtin and call information"
Failing builds: https://lab.llvm.org/buildbot#builders/9/builds/19030 This is GCC specific and ha
Revert "[clang] Use a StringRef instead of a raw char pointer to store builtin and call information"
Failing builds: https://lab.llvm.org/buildbot#builders/9/builds/19030 This is GCC specific and has been reported upstream: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108158
This reverts commit 719d98dfa841c522d8d452f0685e503538415a53.
show more ...
|