Between a PR (124936) adding a base test for dwarf verification JSON
output and a modification of the same in changing the JSON (125062),
there ended up being two versions of the test. The base one and the
fixed one, when there should be only one copy. The base fails as the
JSON format has changed, so deleting that version.
test:
ninja check-llvm-tools-llvm-dwarfdump
It was discovered that BOLT had several distinct issues of missing debug
information by various tags for debug names (119493 & 119023 as
examples), but the verification of a DWARF with llvm-dwarfdump prior to
those fixes only gave one 'missing name' category.
```
{"error-categories":{"Name Index DIE entry missing name":{"count":36355210}},"error-count":36355210}
```
To more easily leverage dwarf verification for debug health, the JSON
output will be improved to allow having detailed counts by a
sub-category when it makes sense.
For now, this is only implemented on the missing tags, but can be
extended to more.
```
{"error-categories":{"Name Index DIE entry missing name":{"count":10,"details":{"DW_TAG_inlined_subroutine":1,"DW_TAG_label":1,"DW_TAG_namespace":2,"DW_TAG_subprogram":2,"DW_TAG_variable":4}}},"error-count":10}
```
This diff also modifies the tests created in pull request 124936 (not
yet landed) to ensure the JSON switches. Ideally this lands after that
but it did not correctly create a stack of pull requests.
This patch adds support for properly decoding SHT_LLVM_BB_ADDR_MAP
sections in relocatable object files when the relocation format is CREL.
Reviewers: rlavaee, jh7370, red1bluelost, MaskRay
Reviewed By: MaskRay
Pull Request: https://github.com/llvm/llvm-project/pull/126446
Fix printing the correct file path in the error message when the output
file specified by `--dump-section` cannot be opened
Fixes: #125113 on ELF, MachO, Wasm
These instructions only have one register field in their encoding, so
both registers in the assembly must be the same.
Previously, we were accepting these instructions, but ignoring the
second register operand.
Fixes#126227
RISCV Zicfilp/Zicfiss extensions uses the `.note.gnu.property` section
to store flags indicating the adoption of features based on these
extensions. This patch enables the llvm-readobj/llvm-readelf tools to
dump these flags with the `--note` flag.
Since line zero means "no line information", when symbolizing a location
(an address or an inline frame associated with the address) that has a
line zero location, we shouldn't include other irrelevant data (like
filename) in the result.
When creating `EnumDecl`s from DWARF for Objective-C `NS_ENUM`s, the
Swift compiler tries to figure out if it should perform "swiftification"
of that enum (which involves renaming the enumerator cases, etc.). The
heuristics by which it determines whether we want to swiftify an enum is
by checking the `enum_extensibility` attribute (because that's what
`NS_ENUM` pretty much are). Currently LLDB fails to attach the
`EnumExtensibilityAttr` to `EnumDecl`s it creates (because there's not
enough info in DWARF to derive it), which means we have to fall back to
re-building Swift modules on-the-fly, slowing down expression evaluation
substantially. This happens around
4b3931c8ce/lib/ClangImporter/ImportEnumInfo.cpp (L37-L59)
To speed up Swift exression evaluation, this patch proposes encoding the
C/C++/Objective-C `enum_extensibility` attribute in DWARF via a new
`DW_AT_APPLE_ENUM_KIND`. This would currently be only used from the LLDB
Swift plugin. But may be of interest to other language plugins as well
(though I haven't come up with a concrete use-case for it outside of
Swift).
I'm open to naming suggestions of the various new attributes/attribute
constants proposed here. I tried to be as generic as possible if we
wanted to extend it to other kinds of enum properties (e.g., flag
enums).
The new attribute would look as follows:
```
DW_TAG_enumeration_type
DW_AT_type (0x0000003a "unsigned int")
DW_AT_APPLE_enum_kind (DW_APPLE_ENUM_KIND_Closed)
DW_AT_name ("ClosedEnum")
DW_AT_byte_size (0x04)
DW_AT_decl_file ("enum.c")
DW_AT_decl_line (23)
DW_TAG_enumeration_type
DW_AT_type (0x0000003a "unsigned int")
DW_AT_APPLE_enum_kind (DW_APPLE_ENUM_KIND_Open)
DW_AT_name ("OpenEnum")
DW_AT_byte_size (0x04)
DW_AT_decl_file ("enum.c")
DW_AT_decl_line (27)
```
Absence of the attribute means the extensibility of the enum is unknown
and abides by whatever the language rules of that CU dictate.
This does feel like a big hammer for quite a specific use-case, so I'm
happy to discuss alternatives.
Alternatives considered:
* Re-using an existing DWARF attribute to express extensibility. E.g., a
`DW_TAG_enumeration_type` could have a `DW_AT_count` or
`DW_AT_upper_bound` indicating the number of enumerators, which could
imply closed-ness. I felt like a dedicated attribute (which could be
generalized further) seemed more applicable. But I'm open to re-using
existing attributes.
* Encoding the entire attribute string (i.e., `DW_TAG_LLVM_annotation
("enum_extensibility((open))")`) on the `DW_TAG_enumeration_type`. Then
in LLDB somehow parse that out into a `EnumExtensibilityAttr`. I haven't
found a great API in Clang to parse arbitrary strings into AST nodes
(the ones I've found required fully formed C++ constructs). Though if
someone knows of a good way to do this, happy to consider that too.
Windows x64 Unwind V2 adds epilog information to unwind data:
specifically, the length of the epilog and the offset of each epilog.
The first step to do this is to add markers to the beginning and end of
each epilog when generating Windows x64 code. I've modelled this after
how LLVM was marking ARM and AArch64 epilogs in Windows (and unified the
code between the three).
Summary:
6244dfef5cd45f1395c66abbe061c6a7eb002676 LLVM commit added the ability
for llvm-dwarfdump to specify --verify-json and get a JSON aggregation
of the DWARF errors in a file. This diff improves the testing by
ensuring we validate the expected JSON shape.
A follow up diff will modify the JSON and this ensures we can verify.
Test Plan:
ninja check-llvm-tools-llvm-dwarfdump
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.
