This introduces a substantial (5-10%) regression in .debug_info size, so
we're discussing alternatives in #122742 and #124790.
This reverts commit 7c729418d721147bf1f2b257afd30f84721888ad.
P550 falls between P450 and P650. It has 1 additional FEX pipe over
P450. Mul and cpop latency are 3 instead of 2.
I've set the MicroOpBufferSize to 96 instead of 56 based on the ROB size
measurement from
https://chipsandcheese.com/p/inside-sifives-p550-microarchitecture I
believe we set this value too low for P450 and P650 and should update
them in a separate PR.
getPtrStride returns 0 when the PtrScev is loop-invariant, and this is
not an erroneous value: it returns std::nullopt to communicate that it
was not able to find a valid pointer stride. In analyzeLoop, we call
getPtrStride with a value_or(0) conflating the zero return value with
std::nullopt. Fix this, handling loop-invariant loads correctly.
This call was made unsafe recently, but was not fixed in
db48f1a1764023f8efeb055e343b967d1eb37d19 (the commit that fixed the
parallel code in AsmParser.cpp).
Fixes#123189
Scalable vectorization factors are printed as "vscale x VF" where VF is
the known minimum number of elements, a integer. Currently,
llvm-opt-report always expects a integer (like for vectorization with
fixed-sized vectors), and does not display any vectorization factor in
the output (just 'V', but without a number).
This patch adds support for scalable vectorization factors and prints
them as "VNx<VF>", so for example "VNx4". The "Nx" is used to
differentiate between fixed-sized and scalable factors, and is
consistent with the way LLVM mangles scalable vectors in other places.
Currently, the AMDGPU backend bumps the Stack Pointer
by fixed size offsets in the prolog of device functions, and
restores it by the same amount in the epilog.
Prolog:
sp += frameSize
Epilog:
sp -= frameSize
If a function has dynamic stack realignment,
Prolog:
sp += frameSize + max_alignment
Epilog:
sp -= frameSize + max_alignment
These calculations are not optimal in case of dynamic
stack realignment, and completely fail in case of
dynamic stack readjustment.
This patch uses the saved Frame Pointer to restore SP.
Prolog:
fp = sp
sp += frameSize
Epilog:
sp = fp
In case of dynamic stack realignment, SP is restored from
the saved Base Pointer.
Prolog:
fp = sp + (max_alignment - 1)
fp = fp & (-max_alignment)
bp = sp
sp += frameSize + max_alignment
Epilog:
sp = bp
(Note: The presence of BP has been enforced in case of any
dynamic stack realignment.)
---------
Co-authored-by: Pravin Jagtap <Pravin.Jagtap@amd.com>
Co-authored-by: Matt Arsenault <arsenm2@gmail.com>
This fixes "unused-local-typedef" warnings in 9324e6a7a5.
This adds an option `--remove-note=[name/]type` to selectively delete
notes in ELF files, where `type` is the numeric value of the note type
and `name` is the name of the originator. The name can be omitted, in
which case all notes of the specified type will be removed. For now,
only `SHT_NOTE` sections that are not associated with segments are
handled. The implementation can be extended later as needed.
RFC: https://discourse.llvm.org/t/rfc-llvm-objcopy-feature-for-editing-notes/83491
This adds an option `--remove-note=[name/]type` to selectively delete
notes in ELF files, where `type` is the numeric value of the note type
and `name` is the name of the originator. The name can be omitted, in
which case all notes of the specified type will be removed. For now,
only `SHT_NOTE` sections that are not associated with segments are
handled. The implementation can be extended later as needed.
RFC: https://discourse.llvm.org/t/rfc-llvm-objcopy-feature-for-editing-notes/83491
Alternative to #123137
With -DMACHINE=EM_NONE, machine specific
sections, like SHT_ARM_EXIDX, will fall to parse
and set `Type`.
This triggers msan on
```
yaml2obj llvm-project/llvm/test/tools/yaml2obj/ELF/mips-abi-flags.yaml -DMACHINE=EM_NONE
```
Size is required, so we don't know if it's in
uninitialized state after the previous error.
Triggers msan on llvm/test/tools/yaml2obj/ELF/custom-fill.yaml NOSIZE
test.
We have `Fill` Section with Pattern, but no size. Before the fix it
produced error:
```
YAML:169:5: error: missing required key 'Size'
- Type: Fill
^
YAML:169:5: error: "Size" can't be 0 when "Pattern" is not empty
- Type: Fill
```
The same applies to `MachOYAML::Section` fields `content` and `size`.
However `MachOYAML::Section` matches size first, so on error,
content is not set anyway. Added error checking just in case.
Intel docs have been updated to be similar to AMD and now describe
BSF/BSR as not changing the destination register if the input value was
zero, which allows us to support CTTZ/CTLZ zero-input cases by setting
the destination to support a NumBits result (BSR is a bit messy as it
has to be XOR'd to create a CTLZ result). VIA/Zhaoxin x86_64 CPUs have also
been confirmed to match this behaviour.
This patch adjusts the X86ISD::BSF/BSR nodes to take a "pass through"
argument for zero-input cases, by default this is set to UNDEF to match
existing behaviour, but it can be set to a suitable value if supported.
There are still some limits to this - its only supported for x86_64
capable processors (and I've only enabled it for x86_64 codegen), and
Intel CPUs sometimes zero the upper 32-bits of a pass through register
when used for BSR32/BSF32 with a zero source value (i.e. the whole
64bits may not get passed through).
Fixes#122004
When looking at the slowest lit tests, I'm seeing these four tests take
two to eight minutes. Test coverage on Linux should be sufficient for
the functionality on top of it not really being useful on Windows at
all.
This was observed when hacking on the new premerge in a windows VM.
This matches what MS lib.exe does (and llvm-ar too); when adding files
to an archive, MS lib.exe stores the file name as it was given on the
command line, whereas llvm-lib rewrote it into a relative path name,
relative to the archive location. Such a rewrite makes sense for thin
archives, but not for regular archives. (MS lib.exe doesn't support
producing thin archives; that's an LLVM extension - see the
thin-relative.test testcase.)
The behaviour to rewrite these paths was added in
451c2ef199e9c5163007ac32e2d426fbfb37e664; it is unclear why it was
chosen to do the rewriting for non-thin archives as well. This quirk is
even pointed out in a code comment - but neither the code review at
https://reviews.llvm.org/D57842 nor the linked bug report at
https://crbug.com/41440160 mentions why this is done for all archives,
not only thin ones.
Therefore, assume that this only was done out of convenience, and change
llvm-lib to not adjust the paths for non-thin archives.
Normally, the actual member names doesn't matter for non-thin archives;
however for short import libraries, where each member is named e.g.
"foo.dll", the names do matter. If using llvm-lib to merge two import
libraries (as a non-thin library), preserve the original names rather
than making the member names relative.
This update introduces the ability to filter merged functions during
lookups based on regex patterns derived from call site information in a
previous call to `llvm-gsymutil`. The regex patterns, extracted from
call sites, can then be passed to subsequent calls using the
`--merged-functions-filter` option along with `--merged-functions` and
`--address` (or `--addresses-from-stdin`). This allows for precise
filtering of functions during lookups, giving accurate results for call
stacks that contain merged functions.
Currently Clang only attaches `DW_AT_object_pointer` to
`DW_TAG_subprogram` definitions. LLDB constructs C++ method types from
their `DW_TAG_subprogram` declaration, which is also the point at which
it needs to determine whether a method is static or not. LLDB's
heuristic for this could be very simple if we emitted
`DW_AT_object_pointer` on declarations. But since we don't, LLDB has to
guess whether an argument is an implicit object parameter based on the
DW_AT_name and DW_AT_type.
To simplify LLDB's job (and to eventually support C++23's explicit
object parameters), this patch adds the `DIFlagObjectPointer` to
`DISubprogram` declarations.
For reference, GCC attaches the object-pointer DIE to both the
definition and declaration: https://godbolt.org/z/3TWjTfWon
Fixes https://github.com/llvm/llvm-project/issues/120973
As in #121565 we need to mark all stores as mayStore, hasSideEffects is not
enough to prevent moving loads past the instructions. And marking the
instructions as mayStore is a sensible thing to do on its own.
Adds support to objdump and readobj for reading the `UOP_Epilog` entries
of Windows x64 unwind v2.
`UOP_Epilog` has a weird format:
The first `UOP_Epilog` in the unwind data is the "header":
* The least-significant bit of `OpInfo` is the "At End" flag, which
signifies that there is an epilog at the very end of the associated
function.
* `CodeOffset` is the length each epilog described by the current unwind
information (all epilogs have the same length).
Any subsequent `UOP_Epilog` represents another epilog for the current
function, where `OpInfo` and `CodeOffset` are combined to a 12-bit value
which is the offset of the beginning of the epilog from the end of the
current function. If the offset is 0, then this entry is actually
padding and can be ignored.
This relands f8f8598fd886cddfd374fa43eb6d7d37d301b576
Follow up on #122371:
The problem here is a little subtle: when we dry-run the measurement
phase, we create a LLJIT instance without actually executing the
snippets. The key is, LLJIT has its own TargetMachine which uses triple
designated by LLVM_TARGET_ARCH (which is default to host). On a machine
that does not support Exegesis, the LLJIT would fail to create its
TargetMachine because llvm-exegesis don't even register the host's
target!
Putting this test into any of the target-specific folder won't help,
because it's about the host. And personally I don't really want to use
`exegesis-can-execute-<arch>` for generic tests like this -- it's too
strict as we don't actually need to execute the snippet.
My solution here is creating another test feature which is added only
when LLVM_TARGET_ARCH is supported by llvm-exegesis. This feature is
something in between `<arch>-registered-target` and
`exegesis-can-execute-<arch>`.
As in #121565 we need to mark all stores as mayStore, hasSideEffects is not
enough to prevent moving loads past the instructions. And marking the
instructions as mayStore is a sensible thing to do on its own.
We have a textual representation of contextual profiles for test scenarios, mainly. This patch moves that to YAML instead of JSON. YAML is more succinct and readable (some of the .ll tests should be illustrative). In addition, JSON is parse-able by the YAML reader.
A subsequent patch will address deserialization.
(thanks, @kazutakahirata, for showing me how to use the llvm YAML reader/writer APIs, which I incorrectly thought to be more low-level than the JSON ones!)
When creating a gSYM, `llvm-gsymutil` operates by default in
multi-threaded mode. If merged functions are present, determinism cannot
be guaranteed if parallel processing is enabled.
So, for our merged functions tests, we disable multi-threading during
gSYM creation.
…#121991)"
This reverts commit f8f8598fd886cddfd374fa43eb6d7d37d301b576.
This breaks ARMv7 and s390x buildbot with the following message:
```
llvm-exegesis error: No available targets are compatible with triple "armv8l-unknown-linux-gnueabihf"
FileCheck error: '<stdin>' is empty.
FileCheck command line: /home/tcwg-buildbot/worker/clang-armv7-2stage/stage2/bin/FileCheck /home/tcwg-buildbot/worker/clang-armv7-2stage/llvm/llvm/test/tools/llvm-exegesis/dry-run-measurement.test
```
With the new benchmark phase, `dry-run-measurement`, llvm-exegesis can
run everything except the actual snippet execution. It is useful when we
want to test some parts of the code between the `assemble-measured-code`
and `measure` phase without actually running on native platforms.
LLD (and other Mach-O linkers) when preparing an encryptable binary make
space to leave all the load commands in an non-encrypted page (see [1])
When using objcopy of a small encryptable binary, the code was not
respecting this fact, and the encryptable segments were not kept beyond
the first page. This was obvious for small or empty binaries.
The changes introduced here keep track if a `LC_ENCRYPTION_INFO` or
`LC_ENCRYPTION_INFO_64` has been seen, and in such case, it adds a full
page of offset in order to leave the load commands in its own page
(similar to what LLD is doing).
[1]:
d8e7929312/lld/MachO/SyntheticSections.cpp (L90-L93)
Adding a new flag(`--csprof-max-unsymbolized-context-depth`) to only
limit unsymbolized context depth. Currently,`--csprof-max-context-depth`
applies to both symbolized and unsymbolized profile context, there are
scenarios where `--csprof-max-context-depth` may not be flexible enough,
e.g. if we want to limit the context but still keep all the inlinings
from the leaf frame, we could set the value
csprof-max-unsymbolized-context-depth >= 1.
For Neoverse-N2, mark FP divide and square root instructions as blocking
their pipeline until complete.
This matches the way that blocking integer divide instructions are
marked.
From the Software Optimization Guide, section 3.14 Notes:
1. FP divide and square root operations are performed using an iterative
algorithm and block subsequent similar operations to the same pipeline
until complete.
---------
Co-authored-by: Cullen Rhodes <cullen.rhodes@arm.com>
Recently https://github.com/llvm/llvm-project/pull/120991 broke a couple
of tests.
Also `macho-merged-funcs-dwarf.yaml` was already flaky due to some
non-determinism issues.
Fixing the previous code to not break tests and modifying
`macho-merged-funcs-dwarf.yaml` to fix the non-determinism (which will
be resolved later).
