| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This matches what MS lib.exe does (and llvm-ar too); when adding files
to an archive, MS lib.exe stores the file name as it was given on the
command line, whereas llvm-lib rewrote it into a relative path name,
relative to the archive location. Such a rewrite makes sense for thin
archives, but not for regular archives. (MS lib.exe doesn't support
producing thin archives; that's an LLVM extension - see the
thin-relative.test testcase.)
The behaviour to rewrite these paths was added in
451c2ef199e9c5163007ac32e2d426fbfb37e664; it is unclear why it was
chosen to do the rewriting for non-thin archives as well. This quirk is
even pointed out in a code comment - but neither the code review at
https://reviews.llvm.org/D57842 nor the linked bug report at
https://crbug.com/41440160 mentions why this is done for all archives,
not only thin ones.
Therefore, assume that this only was done out of convenience, and change
llvm-lib to not adjust the paths for non-thin archives.
Normally, the actual member names doesn't matter for non-thin archives;
however for short import libraries, where each member is named e.g.
"foo.dll", the names do matter. If using llvm-lib to merge two import
libraries (as a non-thin library), preserve the original names rather
than making the member names relative.
|
|
- add a test to check values for /machine argument
- add a test to check if machine is correctly inferred from inputs
|
|
This reverts commit 5d529c32cc2d5342a0d183881b6c3023435ed5d3.
|
|
- add a test to check values for /machine argument
- add a test to check if machine is correctly inferred from inputs
|
|
This can be used with /llvmlibthin to create thin archives without an
index, which is a prerequisite for porting
https://reviews.llvm.org/D117284 to lld-link.
Creating files like this is already possible with `llvm-ar rcS`, so this
doesn't add additional problems.
|
|
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.
|
|
(#116250)
This is a follow-up to #115567. Emit an error for invalid function
names, similar to MSVC's `lib.exe` behavior.
Returning an error from `writeImportLibrary` exposed bugs in error
handling by its callers, which have been addressed in this patch.
|
|
|
|
|
|
To support auto-conversion on z/OS text files need to be opened as text files. These changes will fix a number of LIT failures due to text files not being converted to the internal code page.
update a number of tools so they open the text files as text files
add support in the cat.py to open a text file as a text file (Windows will continue to treat all files as binary so new lines are handled correctly)
add env var definitions to enable auto-conversion in the lit config file.
|
|
(#81600)
It's not interesting for majority of downstream users.
|
|
This can be used to create import libraries that contain both ARM64EC
and native exports. The implementation follows observed MSVC lib.exe
behaviour. It's ignored on targets other than ARM64EC.
|
|
|
|
Summary:
llvm-ar is symlinked as llvm-ranlib and will act as ranlib when invoked in that mode. llvm-ar since [[ https://github.ibm.com/compiler/llvm-project/commit/4f2cfbe5314b064625b2c87bde6ce5c8d04004c5 | compiler/llvm-project@4f2cfbe ]] supports the -X options, but doesn't seem to accept them when running as llvm-ranlib.
In AIX OS , according to https://www.ibm.com/docs/en/aix/7.2?topic=r-ranlib-command
-X mode Specifies the type of object file ranlib should examine. The mode must be one of the following:
32
Processes only 32-bit object files
64
Processes only 64-bit object files
32_64, any
Processes both 32-bit and 64-bit object files
The default is to process 32-bit object files (ignore 64-bit objects). The mode can also be set with the OBJECT_MODE environment variable. For example, OBJECT_MODE=64 causes ranlib to process any 64-bit objects and ignore 32-bit objects. The -X flag overrides the OBJECT_MODE variable.
Reviewers: James Henderson, MaskRay, Stephen Peckham
Differential Revision: https://reviews.llvm.org/D142660
|
|
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 is failing on bots, reverting to investigate.
This reverts commit a16104e6da6f36f3d72dbf53d10ba56495a0d65a.
|
|
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
|
|
In llvm-lib cases, the MinGW specific behaviours shouldn't be
enabled.
Not adding any tests to check the corner case behaviours, as this
simply was a mistake when this codepath was added in
395ec4458fb7fc700551f7017c0a395d68c55873 / D144765.
Differential Revision: https://reviews.llvm.org/D152362
|
|
Similar to D125411, but for ARM64X.
ARM64X PE binaries are hybrids containing both ARM64EC and pure ARM64
variants in one file. They are usually linked by passing separate
ARM64EC and ARM64 object files to linker. Linked binaries use ARM64
machine and contain additional CHPE metadata in their load config.
CHPE metadata support is not part of this patch, I plan to send that later.
Using ARM64X as a machine type of object files themselves is somewhat
ambiguous, but such files are allowed by MSVC. It treats them as ARM64
or ARM64EC object, depending on the context. Such objects can be
produced with cvtres.exe -machine:arm64x.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D148517
|
|
ARM64EC allows having both pure ARM64 objects and ARM64EC in the
same archive. This allows using single static library for linking
pure ARM64, pure ARM64EC or mixed modules (what MS calls ARM64X:
a single module that may be used in both modes). To achieve that,
such static libraries need two separated symbol maps. The usual map
contains only pure ARM64 symbols, while a new /<ECSYMBOLS>/ section
contains EC symbols. EC symbols map has very similar format to the
usual map, except it doesn't contain object offsets and uses offsets
from regular map instead. This is true even for pure ARM64EC static
library: it will simply have 0 symbols in the symbol map.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D143541
|
|
use this format).
We currently just use GNU format for llvm-lib. This mostly works, but
ARM64EC needs an additional section that does not really fit GNU format.
This patch implements writing in COFF format (as in, it's what archive
reader considers as K_COFF). This mostly requires symbol emitting symbol
map. Note that, just like in case of MSVC, symbols are de-duplicated in
both usual symbol table and the new symbol map.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D143540
|
|
.def file, functionality supported by 'lib'. This incompatibility is
breaking clang based Windows openmp builds. This revision adds
basic support for this feature to llvm-lib by cloning the corresponding
code from 'dlltool'.
Differential Revision:https://reviews.llvm.org/D144765
|
|
This isn't strictly needed, but this matches how MSVC lib.exe writes to
archives, so this makes llvm-lib more compatible and simplifies comparing
output between tools.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D143536
|
|
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
|
|
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
|
|
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.
|
|
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
|
|
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.
|
|
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
|
|
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.
|
|
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
Differential Revision: https://reviews.llvm.org/D139881
|
|
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 is a recommit of 8ae18303f97d5dcfaecc90b4d87effb2011ed82e,
with a few cleanups.
This avoids implicit conversion to StringRef at several points, which in
turns avoid redundant calls to strlen.
As a side effect, this greatly simplifies the implementation of
StrCmpOptionNameIgnoreCase.
It also eventually gives a consistent, humble speedup in compilation
time (timing updated since original commit).
https://llvm-compile-time-tracker.com/compare.php?from=de4b6a1bc64db33643f001ad45fae7b92b4a4688&to=c23a93d1292052b4be2fbe8c586fa31143d0c7ed&stat=instructions:u
Differential Revision: https://reviews.llvm.org/D139274
|
|
This applies to GetEnv and FindInEnvPath.
|
|
Ignore the flag for now, but we can start using it for verbose output if needed.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D130202
|
|
It doesn't look like there is anything llvm-lib needs to handle based on
Microsoft's description of the flag.
https://docs.microsoft.com/en-us/cpp/build/reference/managing-a-library?view=msvc-170
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D129032
|
|
It's not clear what Microsoft's LIB.exe actually does based on the official
description of the flag (link below). We can probably ignore it for now.
https://docs.microsoft.com/en-us/cpp/build/reference/managing-a-library?view=msvc-170
Reviewed By: thieta
Differential Revision: https://reviews.llvm.org/D128458
|
|
|
|
"The /LTCG option to LIB specifies that the inputs from cl.exe include object
files generated by using the /GL compiler option."
Based on Microsoft's description
above (https://docs.microsoft.com/en-us/cpp/build/reference/running-lib?view=msvc-170),
there doesn't seem to be anything llvm-lib needs to do to support the flag.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D126000
|
|
lib.exe by default exits successfully without writing an output
file when no inputs are passed. llvm-lib has the same behavior,
for compatibility.
This behavior interacts poorly with build systems: If a static
library target had no inputs, llvm-lib would not produce an output
file, causing ninja (or make, or a similar system) to successfully
run that step, but then re-run it on the next build.
After this patch, llvm-lib emits a warning in this case, that with
/WX can be turned into an error. That way, ninja (or make, or...)
will mark the initial build as failed.
People who don't like the warning can use /ignore:emptyoutput to
suppress it.
The warning also points out the existing flag /llvmlibempty which
forces creation of an empty .lib file (this is an extension to lib.exe).
Differential Revision: https://reviews.llvm.org/D123517
|
|
To be consistent with other member functions and match the coding standard.
|
|
In future patches I will be setting the IsText parameter frequently so I will refactor the args to be in the following order. I have removed the FileSize parameter because it is never used.
```
static ErrorOr<std::unique_ptr<MemoryBuffer>>
getFile(const Twine &Filename, bool IsText = false,
bool RequiresNullTerminator = true, bool IsVolatile = false);
static ErrorOr<std::unique_ptr<MemoryBuffer>>
getFileOrSTDIN(const Twine &Filename, bool IsText = false,
bool RequiresNullTerminator = true);
static ErrorOr<std::unique_ptr<MB>>
getFileAux(const Twine &Filename, uint64_t MapSize, uint64_t Offset,
bool IsText, bool RequiresNullTerminator, bool IsVolatile);
static ErrorOr<std::unique_ptr<WritableMemoryBuffer>>
getFile(const Twine &Filename, bool IsVolatile = false);
```
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D99182
|
|
Slightly changes the output in error code, but no behavior change in
normal use. This is for preparation for using these two functions
elsewhere.
|
|
No longer rely on an external tool to build the llvm component layout.
Instead, leverage the existing `add_llvm_componentlibrary` cmake function and
introduce `add_llvm_component_group` to accurately describe component behavior.
These function store extra properties in the created targets. These properties
are processed once all components are defined to resolve library dependencies
and produce the header expected by llvm-config.
Differential Revision: https://reviews.llvm.org/D90848
|
|
This fixes PR 42837.
Differential Revision: https://reviews.llvm.org/D84465
|
|
The constructor error out parameter was a bit awkward. Wrap it in a
factory method which can return an error. Make the constructor private.
|
|
provided
Summary:
If no inputs and no output path are provided, llvm-lib should produce a useful error.
Before this, it would fail by reading from an unitialized StringRef.
Reviewed By: vvereschaka
Differential Revision: https://reviews.llvm.org/D79227
|
|
Summary:
Add a new option (/llvmlibempty). If passed and llvm-lib does not give an error, it will create a valid output archive even if empty.
By default, llvm-lib mimicks lib.exe: if given no input files, it doesn't create its output file at all. This is incompatible with some build systems, so we add a command-line option to toggle this compatibility behavior.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D78894
|
|
Use the std::string conversion operator introduced in
d7049213d0fcda691c9e79f9b41e357198d99738.
|
