Fix typo "indicies" (#92232)

Use llvm::endianness::{big,little,native} (NFC)

Note that llvm::support::endianness has been renamed to
llvm::endianness while becoming an enum class as opposed to an
enum. This patch replaces suppo

Use llvm::endianness::{big,little,native} (NFC)

Note that llvm::support::endianness has been renamed to
llvm::endianness while becoming an enum class as opposed to an
enum. This patch replaces support::{big,little,native} with
llvm::endianness::{big,little,native}.

show more ...

Use llvm::endianness (NFC)

Now that llvm::support::endianness has been renamed to
llvm::endianness, we can use the shorter form. This patch replaces
support::endianness with llvm::endianness.

Reland: [ELFAttributeParser] Skip unknown vendor subsections.

An .ARM.attributes section is divided into subsections, each labelled
with a vendor name. There is one standardised vendor name, which m

Reland: [ELFAttributeParser] Skip unknown vendor subsections.

An .ARM.attributes section is divided into subsections, each labelled
with a vendor name. There is one standardised vendor name, which must
be used for all attributes that affect compatibility. Subsections
labelled with other vendor names can be used for optimisation
purposes, but it has to be safe for an object file consumer to ignore
them if it doesn't recognise the vendor name.

LLD currently terminates parsing of the whole attributes section as
soon as it encounters a subsection with a vendor name it doesn't
recognise (which is anything other than the standard one). This can
prevent it from detecting compatibility issues, if a standard
subsection followed the vendor-specific one.

This patch modifies the attribute parser so that unrecognised vendor
subsections are silently skipped, and the subsections beyond them are
still processed.

(Relanded with no change from the original commit 8f208edd44d0832. I
reverted it in 949bb7e4de62cd0 due to widespread buildbot breakage,
failing to notice that 975f71faa72aaaa had already fixed the failing
unit test. Also, the *revert* caused at least one buildbot to fail,
because I switched the affected lld test to making %t a directory, and
then the reverted version tried to treat it as a file without cleaning
the output directory first.)

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

show more ...

Revert "[ELFAttributeParser] Skip unknown vendor subsections."

This reverts commit 8f208edd44d0832ac2580e0ec4238be4ecfd5737.

I completely missed the compiled unit test for ELFAttributeParser,
which

Revert "[ELFAttributeParser] Skip unknown vendor subsections."

This reverts commit 8f208edd44d0832ac2580e0ec4238be4ecfd5737.

I completely missed the compiled unit test for ELFAttributeParser,
which also needs updating. I'll reland this change once I make further
fixes.

show more ...

[ELFAttributeParser] Skip unknown vendor subsections.

An .ARM.attributes section is divided into subsections, each labelled
with a vendor name. There is one standardised vendor name, which must
be u

[ELFAttributeParser] Skip unknown vendor subsections.

An .ARM.attributes section is divided into subsections, each labelled
with a vendor name. There is one standardised vendor name, which must
be used for all attributes that affect compatibility. Subsections
labelled with other vendor names can be used for optimisation
purposes, but it has to be safe for an object file consumer to ignore
them if it doesn't recognise the vendor name.

LLD currently terminates parsing of the whole attributes section as
soon as it encounters a subsection with a vendor name it doesn't
recognise (which is anything other than the standard one). This can
prevent it from detecting compatibility issues, if a standard
subsection followed the vendor-specific one.

This patch modifies the attribute parser so that unrecognised vendor
subsections are silently skipped, and the subsections beyond them are
still processed.

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

show more ...

Move from llvm::makeArrayRef to ArrayRef deduction guides - llvm/ part

Use deduction guides instead of helper functions.

The only non-automatic changes have been:

1. ArrayRef(some_uint8_pointer, 0

Move from llvm::makeArrayRef to ArrayRef deduction guides - llvm/ part

Use deduction guides instead of helper functions.

The only non-automatic changes have been:

1. ArrayRef(some_uint8_pointer, 0) needs to be changed into ArrayRef(some_uint8_pointer, (size_t)0) to avoid an ambiguous call with ArrayRef((uint8_t*), (uint8_t*))
2. CVSymbol sym(makeArrayRef(symStorage)); needed to be rewritten as CVSymbol sym{ArrayRef(symStorage)}; otherwise the compiler is confused and thinks we have a (bad) function prototype. There was a few similar situation across the codebase.
3. ADL doesn't seem to work the same for deduction-guides and functions, so at some point the llvm namespace must be explicitly stated.
4. The "reference mode" of makeArrayRef(ArrayRef<T> &) that acts as no-op is not supported (a constructor cannot achieve that).

Per reviewers' comment, some useless makeArrayRef have been removed in the process.

This is a follow-up to https://reviews.llvm.org/D140896 that introduced
the deduction guides.

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

show more ...

[ARM] Fix bug in also_compatible_with attribute parser

Check ScopedPrinter pointer before attempting to print the attribute's
parsed information.

Patch by Michael Platings and Victor Campos

Review

[ARM] Fix bug in also_compatible_with attribute parser

Check ScopedPrinter pointer before attempting to print the attribute's
parsed information.

Patch by Michael Platings and Victor Campos

Reviewed By: pratlucas

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

show more ...

[llvm] Cleanup header dependencies in ADT and Support

The cleanup was manual, but assisted by "include-what-you-use". It consists in

1. Removing unused forward declaration. No impact expected.
2. R

[llvm] Cleanup header dependencies in ADT and Support

The cleanup was manual, but assisted by "include-what-you-use". It consists in

1. Removing unused forward declaration. No impact expected.
2. Removing unused headers in .cpp files. No impact expected.
3. Removing unused headers in .h files. This removes implicit dependencies and
is generally considered a good thing, but this may break downstream builds.
I've updated llvm, clang, lld, lldb and mlir deps, and included a list of the
modification in the second part of the commit.
4. Replacing header inclusion by forward declaration. This has the same impact
as 3.

Notable changes:

- llvm/Support/TargetParser.h no longer includes llvm/Support/AArch64TargetParser.h nor llvm/Support/ARMTargetParser.h
- llvm/Support/TypeSize.h no longer includes llvm/Support/WithColor.h
- llvm/Support/YAMLTraits.h no longer includes llvm/Support/Regex.h
- llvm/ADT/SmallVector.h no longer includes llvm/Support/MemAlloc.h nor llvm/Support/ErrorHandling.h

You may need to add some of these headers in your compilation units, if needs be.

As an hint to the impact of the cleanup, running

clang++ -E -Iinclude -I../llvm/include ../llvm/lib/Support/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l

before: 8000919 lines
after: 7917500 lines

Reduced dependencies also helps incremental rebuilds and is more ccache
friendly, something not shown by the above metric :-)

Discourse thread on the topic: https://llvm.discourse.group/t/include-what-you-use-include-cleanup/5831

show more ...

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

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

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

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

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

[llvm-readobj, libSupport] - Refine the implementation of the code that dumps build attributes.

This implementation of `ELFDumper<ELFT>::printAttributes()` in llvm-readobj has issues:
1) It crashes

[llvm-readobj, libSupport] - Refine the implementation of the code that dumps build attributes.

This implementation of `ELFDumper<ELFT>::printAttributes()` in llvm-readobj has issues:
1) It crashes when the content of the attribute section is empty.
2) It uses `unwrapOrError` and `reportWarning` calls, though
ideally we want to use `reportUniqueWarning`.
3) It contains a TODO about redundant format version check.

`lib/Support/ELFAttributeParser.cpp` uses a hardcoded constant instead of the named constant.

This patch fixes all these issues.

Differential revision: https://reviews.llvm.org/D92318

show more ...

[RISCV] Support RISC-V ELF attributes sections in llvm-readobj.

Enable llvm-readobj to handle RISC-V ELF attribute sections.

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

[RISCV] ELF attribute section for RISC-V.

Leverage ARM ELF build attribute section to create ELF attribute section
for RISC-V. Extract the common part of parsing logic for this section
into ELFAttri

[RISCV] ELF attribute section for RISC-V.

Leverage ARM ELF build attribute section to create ELF attribute section
for RISC-V. Extract the common part of parsing logic for this section
into ELFAttributeParser.[cpp|h] and ELFAttributes.[cpp|h].

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

show more ...