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

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

[llvm-objdump] Let --symbolize-operands symbolize basic block addresses based on the SHT_LLVM_BB_ADDR_MAP section.

`--symbolize-operands` already symbolizes branch targets based on the disassembly.

[llvm-objdump] Let --symbolize-operands symbolize basic block addresses based on the SHT_LLVM_BB_ADDR_MAP section.

`--symbolize-operands` already symbolizes branch targets based on the disassembly. When the object file is created with `-fbasic-block-sections=labels` (ELF-only) it will include a SHT_LLVM_BB_ADDR_MAP section which maps basic blocks to their addresses. In such case `llvm-objdump` can annotate the disassembly based on labels inferred on this section.

In contrast to the current labels, SHT_LLVM_BB_ADDR_MAP-based labels are created for every machine basic block including empty blocks and those which are not branched into (fallthrough blocks).

The old logic is still executed even when the SHT_LLVM_BB_ADDR_MAP section is present to handle functions which have not been received an entry in this section.

Reviewed By: jhenderson, MaskRay

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

show more ...

[AMDGPU] Add gfx11 subtarget ELF definition

This is the first patch of a series to upstream support for the new
subtarget.

Contributors:
Jay Foad <jay.foad@amd.com>
Konstantin Zhuravlyov <kzhuravl_

[AMDGPU] Add gfx11 subtarget ELF definition

This is the first patch of a series to upstream support for the new
subtarget.

Contributors:
Jay Foad <jay.foad@amd.com>
Konstantin Zhuravlyov <kzhuravl_dev@outlook.com>

Patch 1/N for upstreaming AMDGPU gfx11 architectures.

Reviewed By: foad, kzhuravl, #amdgpu

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

show more ...

[ARM] add Armv9 build attribute

The build attribute number can be found in the Arm ABI addenda32 document:
https://github.com/ARM-software/abi-aa/blob/main/addenda32/addenda32.rst#335target-related-

[ARM] add Armv9 build attribute

The build attribute number can be found in the Arm ABI addenda32 document:
https://github.com/ARM-software/abi-aa/blob/main/addenda32/addenda32.rst#335target-related-attributes

Reviewed By: tmatheson

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

show more ...

[AMDGPU] Add gfx1036 target

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

[AMDGPU] Add gfx940 target

This is target definition only.

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

Cleanup LLVMObject headers

Most notably,

llvm/Object/Binary.h no longer includes llvm/Support/MemoryBuffer.h
llvm/Object/MachOUniversal*.h no longer include llvm/Object/Archive.h
llvm/Object/TapiUn

Cleanup LLVMObject headers

Most notably,

llvm/Object/Binary.h no longer includes llvm/Support/MemoryBuffer.h
llvm/Object/MachOUniversal*.h no longer include llvm/Object/Archive.h
llvm/Object/TapiUniversal.h no longer includes llvm/Object/TapiFile.h

llvm-project preprocessed size:
before: 1068185081
after: 1068324320

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D119457

show more ...

[llvm] Use range-based for loops (NFC)

Move TargetRegistry.(h|cpp) from Support to MC

This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually us

Move TargetRegistry.(h|cpp) from Support to MC

This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually use the target, so we might as well move this out of Support.

This allows us to ensure that Support doesn't have includes from MC/*.

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

show more ...

[Object] Move llvm-nm's symbol version utility to ELFObjectFile::readDynsymVersions

The utility can be reused by llvm-objdump -T.

Reviewed By: jhenderson

Differential Revision: https://reviews.llv

[Object] Move llvm-nm's symbol version utility to ELFObjectFile::readDynsymVersions

The utility can be reused by llvm-objdump -T.

Reviewed By: jhenderson

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

show more ...

[ARM] Fix llvm-objdump disassembly of armv7m object files.

Apparently, the features were getting mixed up, so we'd try to
disassemble in ARM mode. Fix sub-architecture detection to compute the
corre

[ARM] Fix llvm-objdump disassembly of armv7m object files.

Apparently, the features were getting mixed up, so we'd try to
disassemble in ARM mode. Fix sub-architecture detection to compute the
correct triple if we're detecting it automatically, so the user doesn't
need to pass --triple=thumb etc.

It's possible we should be somehow tying the "+thumb-mode" target
feature more directly to Tag_CPU_arch_profile? But this seems to work
reasonably well, anyway.

While I'm here, fix up the other llvm-objdump tests that were explicitly
specifying an ARM triple; that shouldn't be necessary.

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

show more ...

[AMDGPU] Add gfx1035 target

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

Reland "[AMDGPU] Add gfx1013 target"

This reverts commit 211e584fa2a4c032e4d573e7cdbffd622aad0a8f.

Fixed a use-after-free error that caused the sanitizers to fail.

Revert "[AMDGPU] Add gfx1013 target"

This reverts commit ea10a86984ea73fcec3b12d22404a15f2f59b219.

A sanitizer buildbot reports an error.

[AMDGPU] Add gfx1013 target

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

[AMDGPU] Add gfx1034 target

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

[AMDGPU] gfx90a support

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

[llvm-objdump] Support PLT decoding for aarch64_be

Reviewed By: jhenderson

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

Replace `T(x)` with `reinterpret_cast<T>(x)` everywhere it means reinterpret_cast. NFC.

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

Recommit: [llvm-readelf/obj] - Allow dumping of ELF header even if some elements are corrupt.

This is recommit for D90903 with fixes for BB:
1) Used std::move<> when returning Expected<> (http://lab

Recommit: [llvm-readelf/obj] - Allow dumping of ELF header even if some elements are corrupt.

This is recommit for D90903 with fixes for BB:
1) Used std::move<> when returning Expected<> (http://lab.llvm.org:8011/#/builders/112/builds/913)
2) Fixed the name of temporarily file in the file-headers.test (http://lab.llvm.org:8011/#/builders/36/builds/1269)
(a local old temporarily file was used before)

For creating `ELFObjectFile` instances we have the factory method
`ELFObjectFile<ELFT>::create(MemoryBufferRef Object)`.

The problem of this method is that it scans the section header to locate some sections.
When a file is truncated or has broken fields in the ELF header, this approach does
not allow us to create the `ELFObjectFile` and dump the ELF header.

This is https://bugs.llvm.org/show_bug.cgi?id=40804

This patch suggests a solution - it allows to delay scaning sections in the
`ELFObjectFile<ELFT>::create`. It now allows user code to call an object
initialization (`initContent()`) later. With that it is possible,
for example, for dumpers just to dump the file header and exit.
By default initialization is still performed as before, what helps to keep
the logic of existent callers untouched.

I've experimented with different approaches when worked on this patch.
I think this approach is better than doing initialization of sections (i.e. scan of them)
on demand, because normally users of `ELFObjectFile` API expect to work with a valid object.
In most cases when a section header table can't be read (because of an error), we don't
have to continue to work with object. So we probably don't need to implement a more complex API.

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

show more ...

Revert "[llvm-readelf/obj] - Allow dumping of ELF header even if some elements are corrupt."

This reverts commit ea8a0b8b29eb08d3f0f6ac40942a2d8e98ab57ee.

It broke BBots.
http://lab.llvm.org:8011/#

Revert "[llvm-readelf/obj] - Allow dumping of ELF header even if some elements are corrupt."

This reverts commit ea8a0b8b29eb08d3f0f6ac40942a2d8e98ab57ee.

It broke BBots.
http://lab.llvm.org:8011/#/builders/14/builds/1439
http://lab.llvm.org:8011/#/builders/112/builds/913

show more ...

[llvm-readelf/obj] - Allow dumping of ELF header even if some elements are corrupt.

For creating `ELFObjectFile` instances we have the factory method
`ELFObjectFile<ELFT>::create(MemoryBufferRef Obj

[llvm-readelf/obj] - Allow dumping of ELF header even if some elements are corrupt.

For creating `ELFObjectFile` instances we have the factory method
`ELFObjectFile<ELFT>::create(MemoryBufferRef Object)`.

The problem of this method is that it scans the section header to locate some sections.
When a file is truncated or has broken fields in the ELF header, this approach does
not allow us to create the `ELFObjectFile` and dump the ELF header.

This is https://bugs.llvm.org/show_bug.cgi?id=40804

This patch suggests a solution - it allows to delay scaning sections in the
`ELFObjectFile<ELFT>::create`. It now allows user code to call an object
initialization (`initContent()`) later. With that it is possible,
for example, for dumpers just to dump the file header and exit.
By default initialization is still performed as before, what helps to keep
the logic of existent callers untouched.

I've experimented with different approaches when worked on this patch.
I think this approach is better than doing initialization of sections (i.e. scan of them)
on demand, because normally users of `ELFObjectFile` API expect to work with a valid object.
In most cases when a section header table can't be read (because of an error), we don't
have to continue to work with object. So we probably don't need to implement a more complex API.

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

show more ...

[AMDGPU] Add gfx1033 target

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

Change-Id: If2650fc7f31bbdd49c76e74a9ca8e3734d769761

[AMDGPU] Add gfx90c target

This differentiates the Ryzen 4000/4300/4500/4700 series APUs that were
previously included in gfx909.

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

Change-Id:

[AMDGPU] Add gfx90c target

This differentiates the Ryzen 4000/4300/4500/4700 series APUs that were
previously included in gfx909.

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

Change-Id: Ia901a7157eb2f73ccd9f25dbacec38427312377d

show more ...