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.
Implement MSVC's `/DEPENDENTLOADFLAG` as `--dependent-load-flag` and
forward it to COFF.
ld.bfd doesn't support it, yet at least, but if they later add support for something similar, hopefully they’d agree to the same option name.
There is no solid need for it yet, but it's being considered:
https://github.com/msys2/MINGW-packages/pull/22216#issuecomment-2428417546
GNU ld silently accepts the -rpath option for Windows targets, as a
no-op.
This has lead to some build systems (and users) passing this option
while building for Windows/MinGW, even if Windows doesn't have any
concept like rpath.
Older versions of Conan did include -rpath in the pkg-config files it
generated, see e.g.
17c58f0c61/conans/client/generators/pkg_config.py (L104-L114)
and
17c58f0c61/conans/client/build/compiler_flags.py (L26-L34)
- and see https://github.com/mstorsjo/llvm-mingw/issues/300 for user
reports about this issue.
Recognize the option in LLD for MinGW targets, to improve drop-in
compatibility compared to GNU ld, but produce a warning to alert users
that the option really has no effect for these targets.
0f9fbbb63cfcd2069441aa2ebef622c9716f8dbb changed the version printouts.
This broke linker detection in Meson, when disambiguating between the
ld.lld and lld-link interfaces, in
https://github.com/mesonbuild/meson/blob/1.4.1/mesonbuild/linkers/detect.py#L67,
which checks for the string "(compatible with GNU linkers)" including
the parentheses.
Reinstate the parentheses in the printout here, for compatibility with
Meson. The printout looks a little odd in this form, "LLD 19.0.0
(https://github.com/llvm/llvm-project
173514d58ec4e6166670f1e37a038df3865c8b96) (compatible with GNU
linkers)", but works with Meson.
The Meson check is loosened in https://github.com/mesonbuild/meson/pull/13383,
but existing versions of Meson with the too strict check will be around
for quite some time, so we should only change LLD to the new form once
older versions of Meson aren't used for these targets any longer, i.e.
earliest within a few years.
Added LLVM repository and LLVM revision information for
`lld::getLLDVersion()`
Before this change:
```
hongyuchy@hongyuchy:~/llvm-project/.build_lld_version$ bin/ld.lld --version
LLD 19.0.0 (compatible with GNU linkers)
```
After this change with LLVM_APPEND_VC_REV=on
```
hongyuchy@hongyuchy:~/llvm-project/.build_lld_version$ bin/ld.lld --version
LLD 19.0.0 (https://github.com/yugier/llvm-project.git 4134b33c6a362cb462b335177d6d9e8235f04309), compatible with GNU linkers
```
with LLVM_APPEND_VC_REV=off
```
hongyuchy@hongyuchy:~/llvm-project/.build_lld_version$ bin/ld.lld --version
LLD 19.0.0, compatible with GNU linkers
```
And use it to print the correct default OpenMP version for flang and
flang -fc1.
This change adds an optional `HelpTextsForVariants` to options. This
allows you to change the help text that gets shown in documentation and
`--help` based on the program its being generated for.
As `OptTable` needs to be constexpr compatible, I have used a std::array
of help text variants. Each entry is:
(list of visibilities) - > help text string
So for the OpenMP version we have (flang, fc1) -> "OpenMP version for
flang is...".
So you can have multiple visibilities use the same string. The number of
entries is currently set to 1, and the number of visibilities per entry
is 2, because that's the maximum we need for now. The code is written so
we can increase these numbers later, and the unused elements will be initialised.
I have not applied this to group descriptions just because I don't know
of one that needs changing. It could easily be enabled for those too if
needed. There are minor changes to them just to get it all to compile.
This approach of storing many help strings per option in the 1 driver
library seemed preferable to making a whole new library for Flang (even
if that would mostly be including stuff from Clang).
These were implemented in the COFF linker in
3923e61b96cf90123762f0e0381504efaba2d77a and
d12b99a4313816cf99e97cb5f579e2d51ba72b0b.
This matches the corresponding options in the ELF linker.
This was missed when mass-adding support for other LTO options in
0b51e648307cf6c21c463d3e73e51c03aaa8c9e2.
Group the existing thinlto_cache_dir with these other options in a new
group, next to the other LTO options.
This skips adding the options --thinlto-emit-index-files and
--thinlto-single-module=, which don't seem to have corresponding options
on the lld-link level currently.
This should fix https://github.com/mstorsjo/llvm-mingw/issues/386.
Disallow using the form with a separate argument,
"--thinlto-cache-dir dir", allow only the one with equals,
"--thintlo-cache-dir=dir". This is the only form that actually was
tested when this was added in
f794808bb9ec06966a67fe33d41a13b9601768f8, and matches the ELF side,
where only the form with an equals is supported (and this was also the
case at the time when this option was added to the MinGW linker).
This was present since when the MinGW LLD frontend first was merged in
894dbbe8eb0e3d8fc7d8746a76d2380f0c2b6c0f, where it most probably was a
leftover from earlier evolution of the patch.
This allows avoiding including some stray DWARF sections (e.g. from
toolchain provided files), when writing a PDB file.
While that probably could be considered reasonable default behaviour,
PDB writing and including DWARF sections are two entirely orthogonal
concepts, and GNU ld (which can generate PDB files these days) does
include DWARF unless -S/-s is passed, when creating a PDB.
[RFC](https://discourse.llvm.org/t/rfc-add-build-id-flag-to-lld-link/74661)
Before, lld-link only generate the debug directory containing guid when
generating PDB with the hash of PDB content.
With this change, lld-link can generate the debug directory when only
`/build-id` is given:
1. If generating PDB, `/build-id` is ignored. Same behaviour as before.
2. Not generating PDB, using hash of the binary.
- Not under MinGW, the debug directory is still in `.rdata` section.
- Under MinGW, place the debug directory into new `.buildid` section.
Back when the --icf= option was hooked up in the MinGW frontend in LLD,
in 2017, lld-link didn't support safe ICF, and mapping it to noicf was
suggested in review: https://reviews.llvm.org/D40019
In 2018, in ab038025a50c79a89edb5832b163e8c729ceb703,
lld-link did get support for handling address significance tables,
allowing the ICF to operate safely on more sections.
Later in 2021, lld-link did get support for a separate safe ICF mode in
5bdc5e7efda4100c4d11085c2da8f1fb932ccce4 /
https://reviews.llvm.org/D97436.
Hook this up for the MinGW frontend as well.
Treat this as an alias for the --shared option.
In practice in GNU ld, they aren't exact aliases but there are small
subtle differences in what happens and what doesn't, when they are set,
but those differences are probably not intended by users who might be
using the --dll option (which gets passed by -mdll in the compiler
driver), and the differences are within the area where small details
differ between LLD and GNU ld anyway.
like done in the ELF side
this would allow to use archlinux default mingw flags:
`-Wl,-O1,--sort-common,--as-needed -fstack-protector`
(on archlinux packages use the GNU linker by default)
Many of these options can be passed to the linker by the Clang
driver based on other options passed to Clang, after
a23bf1786be7c0738a4cf999c2957155bb32d5af. Before commit
5c92c9f34a7dba804479acef62c576d1a170ef1f, these were ignored by
lld, but now we're erroring out on the unrecognized options.
The ELF linker has even more LTO options available, but not
all of these are currently settable via the lld-link option
interface, and some aren't set automatically by Clang but only
if the user manually passes them - and thus probably aren't in
wide use so far. (Previously LLD/MinGW would have accepted them
silently but ignored them though.)
Differential Revision: https://reviews.llvm.org/D158887
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
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
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
This reverts commit aa495214b39d475bab24b468de7a7c676ce9e366.
As discussed in https://github.com/llvm/llvm-project/issues/53475 this patch
allows for using LLD-as-a-lib. It also lets clients link only the drivers that
they want (see unit tests).
This also adds the unit test infra as in the other LLVM projects. Among the
test coverage, I've added the original issue from @krzysz00, see:
https://github.com/ROCmSoftwarePlatform/D108850-lld-bug-reproduction
Important note: this doesn't allow (yet) linking in parallel. This will come a
bit later hopefully, in subsequent patches, for COFF at least.
Differential revision: https://reviews.llvm.org/D119049
This patch migrates uses of StringRef::{starts,ends}with_insensitive
to StringRef::{starts,ends}_with_insensitive so that we can use names
similar to those used in std::string_view.
Note that the llvm/ directory has migrated in commit
6c3ea866e93003e16fc55d3b5cedd3bc371d1fde.
I'll post a separate patch to deprecate
StringRef::{starts,ends}with_insensitive.
Differential Revision: https://reviews.llvm.org/D150506
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.
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
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.
This is a fairly large changeset, but it can be broken into a few
pieces:
- `llvm/Support/*TargetParser*` are all moved from the LLVM Support
component into a new LLVM Component called "TargetParser". This
potentially enables using tablegen to maintain this information, as
is shown in https://reviews.llvm.org/D137517. This cannot currently
be done, as llvm-tblgen relies on LLVM's Support component.
- This also moves two files from Support which use and depend on
information in the TargetParser:
- `llvm/Support/Host.{h,cpp}` which contains functions for inspecting
the current Host machine for info about it, primarily to support
getting the host triple, but also for `-mcpu=native` support in e.g.
Clang. This is fairly tightly intertwined with the information in
`X86TargetParser.h`, so keeping them in the same component makes
sense.
- `llvm/ADT/Triple.h` and `llvm/Support/Triple.cpp`, which contains
the target triple parser and representation. This is very intertwined
with the Arm target parser, because the arm architecture version
appears in canonical triples on arm platforms.
- I moved the relevant unittests to their own directory.
And so, we end up with a single component that has all the information
about the following, which to me seems like a unified component:
- Triples that LLVM Knows about
- Architecture names and CPUs that LLVM knows about
- CPU detection logic for LLVM
Given this, I have also moved `RISCVISAInfo.h` into this component, as
it seems to me to be part of that same set of functionality.
If you get link errors in your components after this patch, you likely
need to add TargetParser into LLVM_LINK_COMPONENTS in CMake.
Differential Revision: https://reviews.llvm.org/D137838
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
