AMDGPU: Add basic gfx942 target

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

AMDGPU: Add basic gfx941 target

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

MCInstrAnalysis: make GotPltSectionVA x86-32 specific

GotPltSectionVA is specific to x86-32 PIC PLT entries.
Let's remove the argument from the generic interface.

As a side effect of not requiring

MCInstrAnalysis: make GotPltSectionVA x86-32 specific

GotPltSectionVA is specific to x86-32 PIC PLT entries.
Let's remove the argument from the generic interface.

As a side effect of not requiring .got.plt, this simplification
addresses a subset of https://github.com/llvm/llvm-project/issues/62537
by enabling .plt dumping for some ld.bfd -z now linked x86-32/x86-64 images
without .got.plt

show more ...

[RISCV] Allow llvm-objdump to disassemble objects with unrecognised versions of known extensions

This Moves ELFObjectFile to using
RISCVISAInfo::parseNormalizedArchString which is not an NFC, as the

[RISCV] Allow llvm-objdump to disassemble objects with unrecognised versions of known extensions

This Moves ELFObjectFile to using
RISCVISAInfo::parseNormalizedArchString which is not an NFC, as the test
changes show. D144353 transitioned LLD to using this function, which is
specialised to parsing arch strings in the normalised format specified
in the psABI rather than user-authored strings accepted in `-march`,
which has greater flexibility.

parseNormalizedArchString does not ignore or produce an error for ISA
extensions with a version that isn't recognised/supported by LLVM. As
current GCC is marking its objects with a higher version of the A, F,
and D extensions than LLVM (see [extension versioning
discussion](https://discourse.llvm.org/t/rfc-resolving-issues-related-to-extension-versioning-in-risc-v/68472)
this massively improves the usability of llvm-objdump with such
binaries.

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

show more ...

[Propeller] Make decoding BBAddrMaps trace through relocations

Currently when using the LLVM tools (eg llvm-readobj, llvm-objdump) to
find information about basic block locations using the propeller

[Propeller] Make decoding BBAddrMaps trace through relocations

Currently when using the LLVM tools (eg llvm-readobj, llvm-objdump) to
find information about basic block locations using the propeller tooling
in relocatable object files function addresses are not mapped properly
which causes problems. In llvm-readobj this means that incorrect
function names will be pulled. In llvm-objdum this means that most BBs
won't show up in the output if --symbolize-operands is used. This patch
changes the behavior of decodeBBAddrMap to trace through relocations
to get correct function addresses if it is going through a relocatable
object file. This fixes the behavior in both tools and also other
consumers of decodeBBAddrMap. Some helper functions have been added
in/refactoring done to aid in grabbing BB address map sections now that
in some cases both relocation and BB address map sections need to be
obtained at the same time.

Regression tests moved around/added.

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

show more ...

[Object][NFC] Remove unneeded llvm_unreachable

Reviewed By: MaskRay

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

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

Use llvm::count{lr}_{zero,one} (NFC)

Explicitly more Error when returning it (NFC)

This is an attempt to fix a build failure:

llvm/lib/Object/ELFObjectFile.cpp:300:12: error: call to deleted constructor of 'llvm::Error'
return E;

[llvm-objdump][RISCV] Use new common method to parse ARCH RISCV attribute

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

std::optional::value => operator*/operator->

value() has undesired exception checking semantics and calls
__throw_bad_optional_access in libc++. Moreover, the API is unavailable without
_LIBCPP_NO_E

std::optional::value => operator*/operator->

value() has undesired exception checking semantics and calls
__throw_bad_optional_access in libc++. Moreover, the API is unavailable without
_LIBCPP_NO_EXCEPTIONS on older Mach-O platforms (see
_LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS).

This commit fixes LLVMAnalysis and its dependencies.

show more ...

[Object] llvm::Optional => std::optional

[llvm] Use std::nullopt instead of None (NFC)

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 ma

[llvm] Use std::nullopt instead of None (NFC)

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

show more ...

AttributeParser: Convert Optional to std::optional

[Object] Add some more LoongArch support

Add ELFObjectFileBase::getLoongArchFeatures, and return the proper ELF
relative reloc type for LoongArch.

Reviewed By: MaskRay, SixWeining

Differential Rev

[Object] Add some more LoongArch support

Add ELFObjectFileBase::getLoongArchFeatures, and return the proper ELF
relative reloc type for LoongArch.

Reviewed By: MaskRay, SixWeining

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

show more ...

[Object] Use std::optional in ELFObjectFile.cpp (NFC)

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-ge

[Object] Use std::optional in ELFObjectFile.cpp (NFC)

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

show more ...

[Object] Internalize readBBAddrMapImpl

Remove redundant initialization of Optional (NFC)

[llvm] LLVM_FALLTHROUGH => [[fallthrough]]. NFC

With C++17 there is no Clang pedantic warning or MSVC C5051.

[llvm] Use value instead of getValue (NFC)

[llvm-objdump] Default to --mcpu=future for PPC64

GNU objdump disassembles all unknown instructions by default. Match this user
friendly behavior with the cpu value `future`.

Differential Revision:

[llvm-objdump] Default to --mcpu=future for PPC64

GNU objdump disassembles all unknown instructions by default. Match this user
friendly behavior with the cpu value `future`.

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

show more ...

[Propeller] Encode address offsets of basic blocks relative to the end of the previous basic blocks.

This is a resurrection of D106421 with the change that it keeps backward-compatibility. This mean

[Propeller] Encode address offsets of basic blocks relative to the end of the previous basic blocks.

This is a resurrection of D106421 with the change that it keeps backward-compatibility. This means decoding the previous version of `LLVM_BB_ADDR_MAP` will work. This is required as the profile mapping tool is not released with LLVM (AutoFDO). As suggested by @jhenderson we rename the original section type value to `SHT_LLVM_BB_ADDR_MAP_V0` and assign a new value to the `SHT_LLVM_BB_ADDR_MAP` section type. The new encoding adds a version byte to each function entry to specify the encoding version for that function. This patch also adds a feature byte to be used with more flexibility in the future. An use-case example for the feature field is encoding multi-section functions more concisely using a different format.

Conceptually, the new encoding emits basic block offsets and sizes as label differences between each two consecutive basic block begin and end label. When decoding, offsets must be aggregated along with basic block sizes to calculate the final offsets of basic blocks relative to the function address.

This encoding uses smaller values compared to the existing one (offsets relative to function symbol).
Smaller values tend to occupy fewer bytes in ULEB128 encoding. As a result, we get about 17% total reduction in the size of the bb-address-map section (from about 11MB to 9MB for the clang PGO binary).
The extra two bytes (version and feature fields) incur a small 3% size overhead to the `LLVM_BB_ADDR_MAP` section size.

Reviewed By: jhenderson

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

show more ...

[llvm] Don't use Optional::hasValue (NFC)

This patch replaces Optional::hasValue with the implicit cast to bool
in conditionals only.

Revert "Don't use Optional::hasValue (NFC)"

This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.

Don't use Optional::hasValue (NFC)