Revert "[Propeller] Use Fixed MBB ID instead of volatile MachineBasicBlock::Number."

This reverts commit 6015a045d768feab3bae9ad9c0c81e118df8b04a.

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

Revert "[Propeller] Use Fixed MBB ID instead of volatile MachineBasicBlock::Number."

This reverts commit 6015a045d768feab3bae9ad9c0c81e118df8b04a.

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

show more ...

[Propeller] Use Fixed MBB ID instead of volatile MachineBasicBlock::Number.

Let Propeller use specialized IDs for basic blocks, instead of MBB number.

This allows optimizations not just prior to as

[Propeller] Use Fixed MBB ID instead of volatile MachineBasicBlock::Number.

Let Propeller use specialized IDs for basic blocks, instead of MBB number.

This allows optimizations not just prior to asm-printer, but throughout the entire codegen.
This patch only implements the functionality under the new `LLVM_BB_ADDR_MAP` version, but the old version is still being used. A later patch will change the used version.

####Background
Today Propeller uses machine basic block (MBB) numbers, which already exist, to map native assembly to machine IR. This is done as follows.
- Basic block addresses are captured and dumped into the `LLVM_BB_ADDR_MAP` section just before the AsmPrinter pass which writes out object files. This ensures that we have a mapping that is close to assembly.
- Profiling mapping works by taking a virtual address of an instruction and looking up the `LLVM_BB_ADDR_MAP` section to find the MBB number it corresponds to.
- While this works well today, we need to do better when we scale Propeller to target other Machine IR optimizations like spill code optimization. Register allocation happens earlier in the Machine IR pipeline and we need an annotation mechanism that is valid at that point.
- The current scheme will not work in this scenario because the MBB number of a particular basic block is not fixed and changes over the course of codegen (via renumbering, adding, and removing the basic blocks).
- In other words, the volatile MBB numbers do not provide a one-to-one correspondence throughout the lifetime of Machine IR. Profile annotation using MBB numbers is restricted to a fixed point; only valid at the exact point where it was dumped.
- Further, the object file can only be dumped before AsmPrinter and cannot be dumped at an arbitrary point in the Machine IR pass pipeline. Hence, MBB numbers are not suitable and we need something else.
####Solution
We propose using fixed unique incremental MBB IDs for basic blocks instead of volatile MBB numbers. These IDs are assigned upon the creation of machine basic blocks. We modify `MachineFunction::CreateMachineBasicBlock` to assign the fixed ID to every newly created basic block. It assigns `MachineFunction::NextMBBID` to the MBB ID and then increments it, which ensures having unique IDs.

To ensure correct profile attribution, multiple equivalent compilations must generate the same Propeller IDs. This is guaranteed as long as the MachineFunction passes run in the same order. Since the `NextBBID` variable is scoped to `MachineFunction`, interleaving of codegen for different functions won't cause any inconsistencies.

The new encoding is generated under the new version number 2 and we keep backward-compatibility with older versions.

####Impact on Size of the `LLVM_BB_ADDR_MAP` Section
Emitting the Propeller ID results in a 23% increase in the size of the `LLVM_BB_ADDR_MAP` section for the clang binary.

Reviewed By: tmsriram

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

show more ...

[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] Add ELF section type for offloading objects

Currently we use the `.llvm.offloading` section to store device-side
objects inside the host, creating a fat binary. The contents of these
sectio

[Object] Add ELF section type for offloading objects

Currently we use the `.llvm.offloading` section to store device-side
objects inside the host, creating a fat binary. The contents of these
sections is currently determined by the name of the section while it
should ideally be determined by its type. This patch adds the new
`SHT_LLVM_OFFLOADING` section type to the ELF section types. Which
should make it easier to identify this specific data format.

Reviewed By: jhenderson

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

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-objdump] --private-headers: change errors to warnings for dynamic section dumping

Fix #54456: `objcopy --only-keep-debug` produces a linked image with invalid
empty dynamic section. llvm-objdu

[llvm-objdump] --private-headers: change errors to warnings for dynamic section dumping

Fix #54456: `objcopy --only-keep-debug` produces a linked image with invalid
empty dynamic section. llvm-objdump -p currently reports an error which seems
excessive.

```
% llvm-readelf -l a.out
llvm-readelf: warning: 'a.out': no valid dynamic table was found
...
```

Follow the spirit of llvm-readelf -l (D64472) and report a warning instead.
This allows later files to be dumped despite warnings for an input file, and
improves objdump compatibility in that the exit code is now 0 instead of 1.

```
% llvm-objdump -p a.out # new behavior
...
Program Header:
llvm-objdump: warning: 'a.out': invalid empty dynamic section
% objdump -p a.out
...
Dynamic Section:

```

Reviewed By: jhenderson, raj.khem

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

show more ...

[LoongArch 2/6] Add ELF machine flag and relocs for upcoming LoongArch target

This patch adds necessary definitions for LoongArch ELF files, including
relocation types. Also adds initial support to

[LoongArch 2/6] Add ELF machine flag and relocs for upcoming LoongArch target

This patch adds necessary definitions for LoongArch ELF files, including
relocation types. Also adds initial support to ELFYaml, llvm-objdump,
and llvm-readobj in order to work with LoongArch ELFs.

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

show more ...

[VE] Support R_VE_RELATIVE

Change getELFRelativeRelocationType() to return R_VE_RELATIVE
as a preparation of lld for VE.

Reviewed By: simoll

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

Make the BBAddrMap struct binary-format-agnostic.

The only binary-format-related field in the BBAddrMap structure is the function address (`Addr`), which will use uint64_t in 64B format and uint32_t

Make the BBAddrMap struct binary-format-agnostic.

The only binary-format-related field in the BBAddrMap structure is the function address (`Addr`), which will use uint64_t in 64B format and uint32_t in 32B format. This patch changes it to use uint64_t in both formats.
This allows non-templated use of the struct, at the expense of a marginal additional size overhead for the 32-bit format. The size of the BB address map section does not change.

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

show more ...

[Object] Simplify RELR decoding

[llvm-objdump/llvm-readobj/obj2yaml/yaml2obj] Support STO_RISCV_VARIANT_CC and DT_RISCV_VARIANT_CC

STO_RISCV_VARIANT_CC marks that a symbol uses a non-standard calling
convention or the vector calli

[llvm-objdump/llvm-readobj/obj2yaml/yaml2obj] Support STO_RISCV_VARIANT_CC and DT_RISCV_VARIANT_CC

STO_RISCV_VARIANT_CC marks that a symbol uses a non-standard calling
convention or the vector calling convention.

See https://github.com/riscv/riscv-elf-psabi-doc/pull/190

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

show more ...

[llvm-readobj] Support dumping of MSP430 ELF attributes

The MSP430 ABI supports build attributes for specifying
the ISA, code model, data model and enum size in ELF object files.

Differential Revis

[llvm-readobj] Support dumping of MSP430 ELF attributes

The MSP430 ABI supports build attributes for specifying
the ISA, code model, data model and enum size in ELF object files.

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

show more ...

[Object] Add missing PPC_DYNAMIC_TAG macros

[llvm-readelf] Support dumping the BB address map section with --bb-addr-map.

This patch lets llvm-readelf dump the content of the BB address map
section in the following format:
```
Function {
At

[llvm-readelf] Support dumping the BB address map section with --bb-addr-map.

This patch lets llvm-readelf dump the content of the BB address map
section in the following format:
```
Function {
At: <address>
BB entries [
{
Offset: <offset>
Size: <size>
Metadata: <metadata>
},
...
]
}
...
```

Reviewed By: jhenderson

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

show more ...

[M68k](4/8) MC layer and object file support

- Add the M68k-specific MC layer implementation
- Add ELF support for M68k
- Add M68k-specifc CC and reloc

TODO: Currently AsmParser and disassembler

[M68k](4/8) MC layer and object file support

- Add the M68k-specific MC layer implementation
- Add ELF support for M68k
- Add M68k-specifc CC and reloc

TODO: Currently AsmParser and disassembler are not implemented yet.
Please use this bug to track the status:
https://bugs.llvm.org/show_bug.cgi?id=48976

Authors: myhsu, m4yers, glaubitz

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

show more ...

Use DataExtractor to decode SLEB128 in android_relas.

A simple refactoring patch which let us use `DataExtractor::getSLEB128` rather than using a lambda function.

Differential Revision: https://rev

Use DataExtractor to decode SLEB128 in android_relas.

A simple refactoring patch which let us use `DataExtractor::getSLEB128` rather than using a lambda function.

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

show more ...

[llvm] Use llvm::lower_bound and llvm::upper_bound (NFC)

[llvm-readelf/obj] - Handle out-of-order PT_LOADs better.

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

Specification says that
"Loadable segment entries in the program header table appear
i

[llvm-readelf/obj] - Handle out-of-order PT_LOADs better.

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

Specification says that
"Loadable segment entries in the program header table appear
in ascending order, sorted on the p_vaddr member."

Our `toMappedAddr()` relies on this condition. This patch
adds a warning when the sorting order of loadable segments is wrong.
In this case we force segments sorting and that allows
`toMappedAddr()` to work as expected.

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

show more ...

Introduce and use a new section type for the bb_addr_map section.

This patch lets the bb_addr_map (renamed to __llvm_bb_addr_map) section use a special section type (SHT_LLVM_BB_ADDR_MAP) instead of

Introduce and use a new section type for the bb_addr_map section.

This patch lets the bb_addr_map (renamed to __llvm_bb_addr_map) section use a special section type (SHT_LLVM_BB_ADDR_MAP) instead of SHT_PROGBITS. This would help parsers, dumpers and other tools to use the sh_type ELF field to identify this section rather than relying on string comparison on the section name.

Reviewed By: jhenderson

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

show more ...

[lib/Object] - Refine interface of ELFFile<ELFT>. NFCI.

`ELFFile<ELFT>` has many methods that take pointers,
though they assume that arguments are never null and
hence could take references instead.

[lib/Object] - Refine interface of ELFFile<ELFT>. NFCI.

`ELFFile<ELFT>` has many methods that take pointers,
though they assume that arguments are never null and
hence could take references instead.

This patch performs such clean-up.

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

show more ...

[ELF] Add a new e_machine value EM_CSKY and add some CSKY relocation types

This is the split part of D86269, which add a new ELF machine flag called EM_CSKY and related relocations.
Some target-spec

[ELF] Add a new e_machine value EM_CSKY and add some CSKY relocation types

This is the split part of D86269, which add a new ELF machine flag called EM_CSKY and related relocations.
Some target-specific flags and tests for csky can be added in follow-up patches later.

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

show more ...

[llvm-readobj] - Make decode_relrs() don't return Expected<>. NFCI.

The `decode_relrs` helper is declared as:

`Expected<std::vector<Elf_Rel>> decode_relrs(Elf_Relr_Range relrs) const;`

it never re

[llvm-readobj] - Make decode_relrs() don't return Expected<>. NFCI.

The `decode_relrs` helper is declared as:

`Expected<std::vector<Elf_Rel>> decode_relrs(Elf_Relr_Range relrs) const;`

it never returns an error though and hence can be simplified to return
a vector.

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

show more ...

[llvm-readobj] - Refactor how the code dumps relocations.

There is a strange "feature" of the code: it handles all relocations as `Elf_Rela`.
For handling `Elf_Rel` it converts them to `Elf_Rela` an

[llvm-readobj] - Refactor how the code dumps relocations.

There is a strange "feature" of the code: it handles all relocations as `Elf_Rela`.
For handling `Elf_Rel` it converts them to `Elf_Rela` and passes `bool IsRela` to
specify the real type everywhere.

A related issue is that the
`decode_relrs` helper in lib/Object has to return `Expected<std::vector<Elf_Rela>>`
because of that, though it could return a vector of `Elf_Rel`.

I think we should just start using templates for relocation types, it makes the code
cleaner and shorter. This patch does it.

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

show more ...

[VE] Implements minimum MC layer for VE (3/4)

Summary:
Define ELF binary code for VE and modify code where should use this new code.

Depends on D79544.

Reviewed By: jhenderson

Differential Revisi

[VE] Implements minimum MC layer for VE (3/4)

Summary:
Define ELF binary code for VE and modify code where should use this new code.

Depends on D79544.

Reviewed By: jhenderson

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

show more ...

[Object] Remove unused variable after D79560. NFC.