Add file with Xtensa ELF relocations. Add Xtensa support to ELF.h,
ELFObject.h and ELFYAML.cpp. Add simple test of Xtensa ELF representation in YAML.
Differential Revision: https://reviews.llvm.org/D64827
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
Summary:
llvm-readobj decide whether to decode the external symbol's function auxiliary entry based on whether symbol is function or not currently. But the XCOFFSymbolRef::isFunction() do not work properly when -ffunction-sections is enabled. we will not decode the function auxiliary entry based on the XCOFFSymbolRef::isFunction()
we will decode the function auxiliary entry based on following:
According to the https://www.ibm.com/docs/en/aix/7.2?topic=formats-xcoff-object-file-format#XCOFF__c0f91ad419jbau
In XCOFF32, there are only "one csect Auxiliary Entry" and "a function auxiliary symbol table entry" for the C_EXT, C_WEAKEXT, and C_HIDEXT Symbols. and By convention, the csect auxiliary entry in an XCOFF32 file must be the last auxiliary entry for any external symbol that has more than one auxiliary entry( that means for the C_EXT, C_WEAKEXT, and C_HIDEXT Symbols. if there more than one auxiliary Entries. we look the last one as csect auxiliary entry. and others auxiliary entries as function entries).
Reviewers: Hubert Tong, James Henderson
Differential Revision: https://reviews.llvm.org/D136950
These weren't running anywhere because of bad specifications.
One test has bit-rotted and had to be XFAILed, the rest are okay.
Differential Revision: https://reviews.llvm.org/D136612
readelf --section-details displays ch_type/ch_size/ch_addralign for
a SHF_COMPRESSED section. Port the feature. There is a small difference
that readelf doesn't display `[<corrupt>]` for an empty section while
we do.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D136636
The current implementation outputs JSON in the following way:
[{'<filename>':{'FileSummary':{},...}}]
Using the filename as a key makes processing the JSON data awkward, and
should be avoided. This patch removes that outer key, since the
'FileSummary' data also includes a 'File' field, and so we lose no data.
Reviewed By: jhenderson, leonardchan
Differential Revision: https://reviews.llvm.org/D134843
The e_flags of existing object files are all 0x3 which happens to be
compatible. From this commit on, all LoongArch objects produced with
upstream LLVM will be of object file ABI v1, which is already supported
by binutils' master branch (to be released as 2.40), and is allowed by
the same binutils version to interlink with v0 objects so the existing
distributions have time to migrate.
Differential Revision: https://reviews.llvm.org/D134601
Unfortunately, we have a broken handling of this in the runtime of rocm
5.3. The runtime is expected to handle this correctly when v5 becomes
the default.
Differential Revision: https://reviews.llvm.org/D134714
This is primarily used for Arm64EC, but it could be used for other
non-standard calling conventions. The testcase is based on an Arm64EC
thunk generated by MSVC.
The name save_any_reg comes from Microsoft documentation, but the full
encoding isn't specified there; this is reverse-engineered from the
behavior of the unwinder. (Thanks to Martin Storsjö for his example of
how to write simple unwinder testcases by directly calling
RtlVirtualUnwind.)
Differential Revision: https://reviews.llvm.org/D135196
When there are no section headers section information printed by llvm-readelf is not useful and unnecessarily verbose. When there are no program headers there's a similar verbose output shown when section mapping is requested. Simplifying the message shown in these cases to match the behavior of `GNU binuntils readelf`.
Reviewed By: jhenderson, MaskRay
Differential Revision: https://reviews.llvm.org/D130670
This change introduces the dynamic stack boolean field to code-object-v3
and above under the code properties of the kernel descriptor and under
the kernel metadata map of NT_AMDGPU_METADATA. This field corresponds to
the is_dynamic_callstack field of amd_kernel_code_t.
Differential Revision: https://reviews.llvm.org/D128344
This patch drops the prefix `PT_RISCV_` when dumping `PT_RISCV_ATTRIBUTES`.
GNU readelf dumps it as `RISCV_ATTRIBUT`. Because GNU readelf uses
something like `%-14.14s` so only the first 14 bytes are printed.
Differential Revision: https://reviews.llvm.org/D128493
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
Fix a couple minor details in the existing logic for calculating
saved registers and stack adjustment.
Synthesize the corresponding prologues and epilogues and print them.
(This supersedes the previous printout of one single list of stored
registers; as there's lots of minor nuance differences in how
registers are pushed/popped in various corner cases, it's better to
print the full prologue/epilogue instead of trying to condense it
into one single list.)
Print the raw values of the fields Reg, R, L (LinkRegister) and C
(Chaining) instead of only printing the derived values.
Differential Revision: https://reviews.llvm.org/D125644
The existing code was essentially untested; in some cases, it used
too narrow variable types to fit all the bits, in some cases the
bit manipulation operations were incorrect.
For the "ldr lr, [sp], #x" opcode, there's nothing in the documentation
that says it cannot be used in a prologue. (In practice, it would
probably seldom be used there, but technically there's nothing
stopping it from being used.) The documentation only specifies the
operation to replay for unwinding it, but the corresponding mirror
instruction to be printed for a prologue is "str lr, [sp, #-x]!".
Also improve printing of register masks, by aggregating registers
into ranges where possible, and make the printing of the terminating
branches clearer, as "bx <reg>" and "b.w <target>".
Differential Revision: https://reviews.llvm.org/D125643
SUMMARY
1. Enable supporting the write operation of big archive.
2. the first commit come from https://reviews.llvm.org/D104367
3. refactor the first commit and implement writing symbol table.
4. fixed the bugs and add more test cases in the second commit.
Reviewers: James Henderson
Differential Revision: https://reviews.llvm.org/D123949
If the function has homed parameters but the number of saved registers
is odd, the homed parameters are aligned at the top of the stack (so
they line up with later varargs on the stack), not tightly after the
other saved registers.
Differential Revision: https://reviews.llvm.org/D125462
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
Summary:
when run "llvm-ar cr" on AIX OS , it created a gnu archive, it is not desirable in aix OS.
instead of creating a gnu archive, the patch will print a unsupport message for llvm-ar big archive write operation in AIX OS.
after implement the big archive operation, I will revert the XFAIL: AIX " and "--format=gnu" test cases in the patch.
Reviewer : James Henderson, Jinsong Ji
Differential Revision: https://reviews.llvm.org/D122746
https://reviews.llvm.org/D116787
This reverts commit 33b3c86afa.
New change: fixed build failures:
- in stabs-sorted:restore the the ERR-KEY statements, which were accidentally deleted during refactoring
- in ObjDumper.h/MachODumper.cpp: refactor so that current dumpers which didn't provide an impl that accept a SymCom still works
Summary:
Address post-commit review comments in the https://reviews.llvm.org/D82549, including
changed file name from llvm/test/tools/llvm-readobj/XCOFF/xcoff-auxiliary-header.test --> llvm/test/tools/llvm-readobj/XCOFF/auxiliary-header.test
replaced macro define by using lambda function.
added a helper function to reduce the duplicated check and print error code.
Reviewer : James Henderson
Differential Revision: https://reviews.llvm.org/D116220
This ELF note is aarch64 and Android-specific. It specifies to the
dynamic loader that specific work should be scheduled to enable MTE
protection of stack and heap regions.
Current synthesis of the ".note.android.memtag" ELF note is done in the
Android build system. We'd like to move that to the compiler, and this
is the first step.
Reviewed By: MaskRay, jhenderson
Differential Revision: https://reviews.llvm.org/D119381
This aids debugging when working with possibly broken files,
instead of just flat out erroring out without telling what's wrong.
Differential Revision: https://reviews.llvm.org/D120679
Instead of the GNU extension `SHF_GNU_RETAIN`, Solaris provides equivalent
functionality with `SHF_SUNW_NODISCARD`. This patch implements the necessary
support.
Tested on `sparcv9-sun-solaris2.11`, `amd64-pc-solaris2.11`, and
`x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D107955
Conceptually, the new encoding emits the offsets and sizes as label differences between each two consecutive basic block begin and end label. When decoding, the offsets must be aggregated along with basic block sizes to calculate the final relative-to-function offsets of basic blocks.
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 25% reduction
in the size of the bb-address-map section (reduction from about 9MB to 7MB).
Reviewed By: tmsriram, jhenderson
Differential Revision: https://reviews.llvm.org/D106421
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
