| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Summary:
This patch has broken the `libc` build bot. I could work around that but
the changes seem unnecessary.
This reverts commit 9ba844eb3a21d461c3adc7add7691a076c6992fc.
|
|
When handling CUDA ELF files via objdump or LLDB, the ELF parser in LLVM
needs to distinguish if an ELF file is sass or not, which requires a
triple for sass to exist in llvm. This patch includes all the necessary
changes for LLDB and objdump to correctly identify these files with the
correct triple.
|
|
(#155041)
This PR simply moves the callsite anchors from the beginning of
callsites to their end.
Emitting the end of callsites is more sensible as it allows breaking the
basic block into subblocks which end with control transfer instructions.
|
|
Add support for big-endian RISC-V ELF files:
- Add riscv32be/riscv64be target architectures to Triple
- Support elf32-bigriscv and elf64-bigriscv output targets in
llvm-objcopy
- Update ELFObjectFile to handle BE RISC-V format strings and
architecture detection
- Add BE RISC-V support to RelocationResolver
- Add tests for new functionality
This is a subset of a bigger RISC-V big-endian support patch, containing
only the llvm-objcopy and libObject changes. Other changes will be added
later.
|
|
(SHT_LLVM_BB_ADDR_MAP_V0). (#146186)
Version 2 was added more than two years ago
(https://github.com/llvm/llvm-project/commit/6015a045d768feab3bae9ad9c0c81e118df8b04a).
So it should be safe to deprecate older versions.
|
|
As pointed in #145438, the order of elements in `v2::DescriptorRange` is
wrong according to the root signature file format. This changes the
order and updates the code and test to continue to pass.
Closes: #145438
---------
Co-authored-by: joaosaffran <joao.saffran@microsoft.com>
|
|
newly-introduced SHT_LLVM_BB_ADDR_MAP version. (#144426)
Recently, we have been looking at some optimizations targeting
individual calls. In particular, we plan to extend the address mapping
technique to map to individual callsites. For example, in this piece of
code for a basic blocks:
```
<BB>:
1200: lea 0x1(%rcx), %rdx
1204: callq foo
1209: cmpq 0x10, %rdx
120d: ja L1
```
We want to emit 0x9 as the call site offset for `callq foo` (the offset
from the block entry to right after the call), so that we know if a
sampled address is before the call or after.
This PR implements the decode/encode/emit capability. The Codegen change
will be implemented in a later PR.
|
|
|
|
|
|
- Adds support for static samplers ins dxcontainer binary format.
- Adds writing logic to mcdxbc
- adds reading logic to Object
- adds tests
Closes: [126636](https://github.com/llvm/llvm-project/issues/126636)
---------
Co-authored-by: joaosaffran <joao.saffran@microsoft.com>
|
|
obj2yaml/yaml2obj (#138315)
Closes:
https://github.com/orgs/llvm/projects/4/views/22?sliceBy%5Bvalue%5D=joaosaffran&pane=issue&itemId=97332852&issue=llvm%7Cllvm-project%7C126635
---------
Co-authored-by: joaosaffran <joao.saffran@microsoft.com>
|
|
This makes the test more portable. In google, the test was failing
because a test cannot write to its own directory in a sandbox.
|
|
This patch fixes:
llvm/unittests/Object/OffloadingBundleTest.cpp:56:19: error: unused
variable 'mbuf' [-Werror,-Wunused-variable]
llvm/unittests/Object/OffloadingBundleTest.cpp:57:13: error: unused
variable 'FileName' [-Werror,-Wunused-variable]
llvm/unittests/Object/OffloadingBundleTest.cpp:72:19: error: unused
variable 'mbuf' [-Werror,-Wunused-variable]
llvm/unittests/Object/OffloadingBundleTest.cpp:73:13: error: unused
variable 'FileName' [-Werror,-Wunused-variable]
|
|
Utilize the new extensions to the LLVM Offloading API to extend to
llvm-objdump to handle dumping fatbin offload bundles generated by HIP.
This extension to llvm-objdump adds the option --offload-fatbin.
Specifying this option will take the input object/executable and extract
all offload fatbin bundle entries into distinct code object files with
names reflecting the source file name combined with the Bundle Entry ID.
Users can also use the --arch-name option to filter offload fatbin
bundle entries by their target triple.
---------
Co-authored-by: dsalinas <dsalinas@MKM-L1-DSALINAS.amd.com>
|
|
This reverts commit 910220b84fa18ce2cbb2e21dd53b9f3d0ae582a7.
Multiple buildbot failures have been reported:
https://github.com/llvm/llvm-project/pull/140128
|
|
Utilize the new extensions to the LLVM Offloading API to extend to
llvm-objdump to handle dumping fatbin offload bundles generated by HIP.
This extension to llvm-objdump adds the option --offload-fatbin.
Specifying this option will take the input object/executable and extract
all offload fatbin bundle entries into distinct code object files with
names reflecting the source file name combined with the Bundle Entry ID.
Users can also use the --arch-name option to filter offload fatbin
bundle entries by their target triple.
---------
Co-authored-by: dsalinas <dsalinas@MKM-L1-DSALINAS.amd.com>
|
|
closes: [126634](https://github.com/llvm/llvm-project/issues/126634)
---------
Co-authored-by: joaosaffran <joao.saffran@microsoft.com>
|
|
This reverts commit 06d6623bc304d5fc2fe11b80b62b4c5d10f9eaa1.
Buildbot failure:
https://lab.llvm.org/buildbot/#/builders/145/builds/6871/steps/5/logs/stdio
|
|
Utilize the new extensions to the LLVM Offloading API to extend to
llvm-objdump to handle dumping fatbin offload bundles generated by HIP.
This extension to llvm-objdump adds the option --offload-fatbin.
Specifying this option will take the input object/executable and extract
all offload fatbin bundle entries into distinct code object files with
names reflecting the source file name combined with the Bundle Entry ID.
Users can also use the --arch-name option to filter offload fatbin
bundle entries by their target triple.
---------
Co-authored-by: dsalinas <dsalinas@MKM-L1-DSALINAS.amd.com>
|
|
Adding support for Root Constant in MC, Object and obj2yaml and
yaml2obj, this PR adds:
- new structures to dxbc definition.
- serialize and desirialize logic from dxcontainer to yaml
- tests validating against dxc
- adding support to multiple parts.
Closes: https://github.com/llvm/llvm-project/issues/126633
---------
Co-authored-by: joaosaffran <joao.saffran@microsoft.com>
|
|
Adding support for Root Signature Flags Element extraction and writing
to DXContainer.
- Adding an analysis to deal with RootSignature metadata definition
- Adding validation for Flag
- writing RootSignature blob into DXIL
Closes: [126632](https://github.com/llvm/llvm-project/issues/126632)
---------
Co-authored-by: joaosaffran <joao.saffran@microsoft.com>
|
|
This patch updates the getSectionAndRelocations function to also support
CREL relocation sections. Unit tests have been added. This patch also
updates consumers to say they explicitly do not support CREL format
relocations. Subsequent patches will make the consumers work with CREL
format relocations and also add in testing support.
Reviewers: red1bluelost, MaskRay, rlavaee
Reviewed By: MaskRay
Pull Request: https://github.com/llvm/llvm-project/pull/126445
|
|
|
|
This PR adds:
- `RootSignatureFlags` extraction from DXContainer using `obj2yaml`
This PR is part of: #121493
---------
Co-authored-by: joaosaffran <joao.saffran@microsoft.com>
|
|
content_iterator (#124106)
value_type was defined as non-const for content_iterator, although it's
methods returned a const pointers/references. This prevented it from
using in some algorithms from STLExtras.h
|
|
Sometimes we want to use a `PgoAnalysisMap` feature that doesn't require
the BB entries info, e.g. only the `FuncEntryCount`, but the BB entries
is emitted by default, so I'm adding an option to skip the info for this
case to save the binary size(can save ~90% size of the section). For
implementation, it extends a new field(`OmitBBEntries`) in
`BBAddrMap::Features` for this and it's controlled by a switch
`--basic-block-address-map-skip-bb-entries`.
Note that this naturally supports backwards compatibility as the field
is zero for the old version, matches the decoding in the new version
llvm.
|
|
This is one of the many PRs to fix errors with LLVM_ENABLE_WERROR=on.
Built by GCC 11.
Fix warnining:
llvm/unittests/Object/GOFFObjectFileTest.cpp:511:17: error: overflow in
conversion from ‘int’ to ‘char’ changes value from ‘240’ to
‘'\37777777760'’ [-Werror=overflow]
511 | GOFFData[1] = 0xF0;
|
|
raw_string_ostream::flush() is essentially a no-op (also specified in docs).
Don't call it in tests that aren't meant to test 'raw_string_ostream' itself.
p.s. remove a few redundant calls to raw_string_ostream::str()
|
|
A fork of #97470, splitting off the LLVM changes from the LLDB specific
changes. This patch enables a minidump file to have multiple exceptions,
exposed via an iterator of Expected streams.
|
|
Add ResourceType, ResourceKind and ResourceFlag enum class for PSV
resource.
This is for #103275
|
|
This reapplies
https://github.com/llvm/llvm-project/commit/195d8ac26d91ca798733c3a5f58d67992d43503d
[DirectX] Fix DXIL part header version encoding. The endian issue was
fixed by
https://github.com/llvm/llvm-project/commit/f42117c8517cc928c6373bad35ebf75d94fe865b.
Move MinorVersion be the lower 8 bit.
Set DXIL version in DXContainerObjectWriter::writeObject.
Fixes #89952
|
|
Avoid using bitfield in dxbc::ProgramHeader.
It could potentially be read incorrectly on any host depending on the
compiler.
From [C++17's
[class.bit]](https://timsong-cpp.github.io/cppwp/n4659/class.bit#1)
> Bit-fields are packed into some addressable allocation unit. [ Note:
Bit-fields straddle allocation units on some machines and not on others.
Bit-fields are assigned right-to-left on some machines, left-to-right on
others. — end note ]
For #91793
|
|
Test failures on big endian bots after this change.
Reverts llvm/llvm-project#91506
|
|
Move MinorVersion be the lower 8 bit.
Set DXIL version in DXContainerObjectWriter::writeObject.
Fixes #89952
|
|
Normally, operator< accepting DataRefImpl is used when comparing
SymbolRef/ELFSymbolRef. However, it uses std::memcmp which interprets
DataRefImpl union as char string so that the result depends on host
endianness.
For ELFSymbolRef a specialized operator< can be used instead to produce
consistent ordering regardless of endianness by comparing the symbol
table index and symbol index fields separately.
|
|
This PR adds handling for TXT records in the GOFF reader.
---------
Co-authored-by: Yusra Syeda <yusra.syeda@ibm.com>
|
|
This reverts commit 009f88fc0e3a036be97ef7b222b90af342bae0b7.
Reverting PR due to test failure.
|
|
This PR adds handling for TXT records in the GOFF reader.
---------
Authored-by: Yusra Syeda <yusra.syeda@ibm.com>
|
|
together by decoupling the handling of the two features. (#74128)
Today `-split-machine-functions` and `-fbasic-block-sections={all,list}`
cannot be combined with `-basic-block-sections=labels` (the labels
option will be ignored).
The inconsistency comes from the way basic block address map -- the
underlying mechanism for basic block labels -- encodes basic block
addresses
(https://lists.llvm.org/pipermail/llvm-dev/2020-July/143512.html).
Specifically, basic block offsets are computed relative to the function
begin symbol. This relies on functions being contiguous which is not the
case for MFS and basic block section binaries. This means Propeller
cannot use binary profiles collected from these binaries, which limits
the applicability of Propeller for iterative optimization.
To make the `SHT_LLVM_BB_ADDR_MAP` feature work with basic block section
binaries, we propose modifying the encoding of this section as follows.
First let us review the current encoding which emits the address of each
function and its number of basic blocks, followed by basic block entries
for each basic block.
| | |
|--|--|
| Address of the function | Function Address |
| Number of basic blocks in this function | NumBlocks |
| BB entry 1
| BB entry 2
| ...
| BB entry #NumBlocks
To make this work for basic block sections, we treat each basic block
section similar to a function, except that basic block sections of the
same function must be encapsulated in the same structure so we can map
all of them to their single function.
We modify the encoding to first emit the number of basic block sections
(BB ranges) in the function. Then we emit the address map of each basic
block section section as before: the base address of the section, its
number of blocks, and BB entries for its basic block. The first section
in the BB address map is always the function entry section.
| | |
|--|--|
| Number of sections for this function | NumBBRanges |
| Section 1 begin address | BaseAddress[1] |
| Number of basic blocks in section 1 | NumBlocks[1] |
| BB entries for Section 1
|..................|
| Section #NumBBRanges begin address | BaseAddress[NumBBRanges] |
| Number of basic blocks in section #NumBBRanges |
NumBlocks[NumBBRanges] |
| BB entries for Section #NumBBRanges
The encoding of basic block entries remains as before with the minor
change that each basic block offset is now computed relative to the
begin symbol of its containing BB section.
This patch adds a new boolean codegen option `-basic-block-address-map`.
Correspondingly, the front-end flag `-fbasic-block-address-map` and LLD
flag `--lto-basic-block-address-map` are introduced.
Analogously, we add a new TargetOption field `BBAddrMap`. This means BB
address maps are either generated for all functions in the compiling
unit, or for none (depending on `TargetOptions::BBAddrMap`).
This patch keeps the functionality of the old
`-fbasic-block-sections=labels` option but does not remove it. A
subsequent patch will remove the obsolete option.
We refactor the `BasicBlockSections` pass by separating the BB address
map and BB sections handing to their own functions (named
`handleBBAddrMap` and `handleBBSections`). `handleBBSections` renumbers
basic blocks and places them in their assigned sections.
`handleBBAddrMap` is invoked after `handleBBSections` (if requested) and
only renumbers the blocks.
- New tests added:
- Two tests basic-block-address-map-with-basic-block-sections.ll and
basic-block-address-map-with-mfs.ll to exercise the combination of
`-basic-block-address-map` with `-basic-block-sections=list` and
'-split-machine-functions`.
- A driver sanity test for the `-fbasic-block-address-map` option
(basic-block-address-map.c).
- An LLD test for testing the `--lto-basic-block-address-map` option.
This reuses the LLVM IR from `lld/test/ELF/lto/basic-block-sections.ll`.
- Renamed and modified the two existing codegen tests for basic block
address map (`basic-block-sections-labels-functions-sections.ll` and
`basic-block-sections-labels.ll`)
- Removed `SHT_LLVM_BB_ADDR_MAP_V0` tests. Full deprecation of
`SHT_LLVM_BB_ADDR_MAP_V0` and `SHT_LLVM_BB_ADDR_MAP` version less than 2
will happen in a separate PR in a few months.
|
|
unspecified. (#79168)
Turns out the problem with
https://github.com/llvm/llvm-project/issues/60013 is due to the fact
that order of operation is unspecified in C++:
https://en.cppreference.com/w/cpp/language/eval_order. A small example
of where this manifests with MSVC can be seen here
https://ooo.godbolt.org/z/bxqKeqzqn.
This patch does the following:
* Removes the addition operations where we sequence more than one
side-effect based expression.
* Removes test guards to now run on Windows
|
|
failures to test cases. (#78335)
Although parameterized gtests are preferred for this, our tests are not
very straightforward. So I decided to add SCOPED_TRACE for different
test cases and the lambda checks as well.
Typical test failure message now looks like:
```
...llvm-project/llvm/unittests/Object/ELFObjectFileTest.cpp:737
Expected equality of these values:
*BBAddrMaps
Which is: { 32-byte object <11-11 01-00 00-00 00-00 C0-A9 FB-3E E4-55 00-00 D0-A9 FB-3E E4-55 00-00 D0-A9 FB-3E E4-55 00-00>, 32-byte object <22-22 02-00 00-00 00-00 F0-8E FB-3E E4-55 00-00 00-8F FB-3E E4-55 00-00 00-8F FB-3E E4-55 00-00> }
ExpectedResult
Which is: { 32-byte object <33-33 03-00 00-00 00-00 50-A7 FB-3E E4-55 00-00 60-A7 FB-3E E4-55 00-00 60-A7 FB-3E E4-55 00-00> }
Google Test trace:
...llvm-project/llvm/unittests/Object/ELFObjectFileTest.cpp:726: for TextSectionIndex: 1 and object yaml:
--- !ELF
FileHeader:
Class: ELFCLASS64
Data: ELFDATA2LSB
Type: ET_EXEC
Sections:
- Name: .llvm_bb_addr_map_1
Type: SHT_LLVM_BB_ADDR_MAP
Link: 1
Entries:
- Version: 2
Address: 0x11111
BBEntries:
- ID: 1
AddressOffset: 0x0
Size: 0x1
Metadata: 0x2
- Name: .llvm_bb_addr_map_2
Type: SHT_LLVM_BB_ADDR_MAP
Link: 1
Entries:
- Version: 2
Address: 0x22222
BBEntries:
- ID: 2
AddressOffset: 0x0
Size: 0x2
Metadata: 0x4
- Name: .llvm_bb_addr_map_3
Type: SHT_LLVM_BB_ADDR_MAP
Link: 2
Entries:
- Version: 1
Address: 0x33333
BBEntries:
- ID: 0
AddressOffset: 0x0
Size: 0x3
Metadata: 0x6
- Name: .llvm_bb_addr_map_4
Type: SHT_LLVM_BB_ADDR_MAP_V0
# Link: 0 (by default, can be overriden)
Entries:
- Version: 0
Address: 0x44444
BBEntries:
- ID: 0
AddressOffset: 0x0
Size: 0x4
Metadata: 0x18
...llvm-project/llvm/unittests/Object/ELFObjectFileTest.cpp:757: normal sections
```
|
|
BBAddrMap. (#77139)
We had specified that `readBBAddrMap` will always keep PGOAnalyses and
BBAddrMaps the same length on success.
https://github.com/llvm/llvm-project/blob/365fbbfbcfefb8766f7716109b9c3767b58e6058/llvm/include/llvm/Object/ELFObjectFile.h#L116-L117
It turns out that this is not currently the case when no analyses exist
in a function. No test had caught it.
We also should not append PGOBBEntries when there is no BBFreq or
BrProb.
This patch adds:
* tests that PGOAnalyses and BBAddrMaps are same length even when no
analyses are enabled
* fixes decode so that PGOAnalyses and BBAddrMaps are same length
* updates test to not emit unnecessary PGOBBEntries
* fixes decode to not emit PGOBBEntries when unnecessary
|
|
|
|
Summary:
This formats something according to the style, and again attempts to fix
this failing on the BE PPC test. Sorry for the spam, these commits are
the only way I can check it because the failure isn't local.
|
|
Summary:
This test fails because AMDGPU has a check for little-endianness before
returning the architecture. This test attempts to force the type to be
considered little-endian for the purpose of this test.
|
|
Summary:
This patch fixes up the `makeTriple()` interface to emit append the
operating system information when it is readily avaialble from the ELF.
The main motivation for this is so the GPU architectures can be easily
identified correctly when given and ELF. E.g. we want
`amdgpu-amd-amdhsa` as the output and not `amdgpu--`.
This required adding support for the CUDA OS/ABI, which is easily found
to be `0x33` when using `readelf`.
|
|
with tests.
Reviewed in PR (#71750). A part of [RFC - PGO Accuracy Metrics: Emitting and Evaluating Branch
and Block
Analysis](https://discourse.llvm.org/t/rfc-pgo-accuracy-metrics-emitting-and-evaluating-branch-and-block-analysis/73902).
This PR adds the PGOAnalysisMap data structure and implements encoding and
decoding through Object and ObjectYAML along with associated tests. When
emitted into the bb-addr-map section, each function is followed by the associated
pgo-analysis-map for that function. The emitting of each analysis in the map is
controlled by a bit in the bb-addr-map feature byte. All existing bb-addr-map
code can ignore the pgo-analysis-map if the caller does not request the data.
|
|
psABI v2.20 added R_LARCH_CALL36 and removed R_LARCH_DELETE / R_LARCH_CFA.
R_LARCH_CALL36 was designed for function call on medium code model where
the 2 instructions (pcaddu18i + jirl) must be adjacent.
|
|
BBAddrMap fields. (#72689)
The fields are still kept as public for now since our tooling accesses
them. Will change them to private visibility in a later patch.
|
|
For DirectX, program signatures are encoded into three different binary
sections depending on if the signature is for inputs, outputs, or
patches. All three signature types use the same data structure encoding
so they can share a lot of logic.
This patch adds support for reading and writing program signature data
as both yaml and binary data.
Fixes #57743 and #57744
|
