We don't need to run llvm-exegesis for the regression tests, just dump
the object code, so this adds option
--benchmark-phase=assemble-measured-code to achieve that.
Current implementation (for Aarch64) in llvm-exegesis only supports
GRP32 and GPR64 bit register class, thus for opcodes variants which used
FPR64/128, PPR16 and ZPR128, llvm-exegesis throws warning "setReg is not
implemented". This code will handle the above register class and
initialize the registers using appropriate base instruction class.
The profile format has now a separate section called "Contexts" - there will be a corresponding one for flat profiles. The root has a separate tag because, in addition to not having a callsite ID as all the other context nodes have under it, it will have additional fields in subsequent patches.
The rest of this patch amounts to a bit of refactorings in the reader/writer (for better reuse later) and tests fixups.
Previously, when an inlined library existed in TBD file A but not in file B, all of the inlined library's attributes were printed. This is noisy since the important detail is the complete contents are missing. Instead, only print the install name of the inlined library and the marker for which the input file exists in.
To help make better use of dwarfdump verification for identifying and
fixing issues with debug information, the JSON will now emit details
(sub-categories) where relevant. First modification concerns missing
tags as those were recently missing for BOLT debug names.
Test:
test files for JSON output were previously added, so modify here to
expect the new JSON keys. One test has sub-categories and another is
empty.
ninja check-llvm-tools-llvm-dwarfdump
Also build the tool and run with a local executable to verify.
ninja llvm-dwarfdump
This fix helps to map operand memory to destination registers. If
instruction is load, we can self-alias it in case when instruction
overrides whole address register. For that we use provided scratch
memory.
This patch introduces support for the `DW_AT_LLVM_stmt_sequence`
attribute in the GSYM DWARF transformer. With this change, the DWARF
GSYM creation process can now accurately associate debug information
with the correct functions, even when multiple functions have been
merged together.
The `macho-gsym-merged-callsites-dsym.yaml` test data is regenerated to
include the fixes in the DWARF linker
(https://github.com/llvm/llvm-project/pull/128953) and the test is
updated to check that debug data is correctly associated for merged
functions.
Use `-passes="regallocgreedy<[all|sgpr|wwm|vgpr]>` to insert the greedy
RA with a filter and `-regalloc-npm=<type>` to control which RA to use
in existing pipeline.
It seems like we had been picking the wrong VPseudo scheduling class for
indexed memory operations in RISCVMCACustomBehavior: the VPseudo opcode
of indexed memory ops encode two EMULs, one for index and the other for
data. However, in RISCVInversePseudoTable, we're only able to look up
against one of them, yielding an incorrect VPseudo opcode with the wrong
data EEW (index EEW is encoded in the opcode). Since scheduling classes
for indexed memory ops uses data EMUL / EEW in their scheduling class,
we would eventually fetch the wrong scheduling classes with faulty data
EEW.
This patch fixes this issue by deducting the correct index EMUL with
LMUL (data EMUL), SEW (data EEW), and index EEW. With these parameters
we can thus fetch the correct VPseudo opcode with `getVLXPseudo` /
`getVLXSEGPseudo` and friends.
The new search table, RISCVBaseVXMemOpTable, is created to extract the
NF and index EEW info from MC opcode. Otherwise we need to write a
gigantic switch statement to decode this info.
Sometimes it'll fail to generate any snippet because it's unable to
assign unique def and use registers.
Mark this test as ALLOW_RETRIES. Also, lower the minimum number of
instructions per snippet in the hope to increase the chance of
assigning unique registers for every instructions.
This test was designed to check if we alias between vd and vs2. While we
make sure there is no alias relationship between vd and vs1 in the
snippet generator, there is nothing preventing the randomizer to assign
the same register between vs1 and vs2. Which makes this test pretty
unstable.
However, we really only care if vd and vs2 are alias, so instead of
going an extra mile to check whether vd and vs1 are NOT alias, which is
actually irrelevant, we should just focusing on checking if vd and vs2
are alias.
Under expensive checks, some of the tests will fail to pass the
MachineVerifier. It's because right after a snippet is generated, its VL
operand (if it's a register) is assigned a physical register. While
we'll replace it with virtual register in RISCVExegesisPreprocessing,
it's technically violating RISCVInstrInfo's validation rule.
Under normal circumstances, this won't trigger a MachineVerifier failure
because the codegen pipeline doesn't validate the code until the very
end -- which is not the case under EXPENSIVE_CHECKS where
MachineVerifierPass is sprinkled here and there.
This is really caused by the fact that RISCV exegesis has an odd
"codegen" Pass pipeline. And I don't have a good solution yet, so I'm
surpressing these tests under EXPENSIVE_CHECKS.
PTX supports 2 methods of accessing device function parameters:
- "simple" case: If a parameters is only loaded, and all loads can
address the parameter via a constant offset, then the parameter may be
loaded via the ".param" address space. This case is not possible if the
parameters is stored to or has it's address taken. This method is
preferable when possible.
- "move param" case: For more complex cases the address of the param may
be placed in a register via a "mov" instruction. This mov also
implicitly moves the param to the ".local" address space and allows for
it to be written to. This essentially defers the responsibilty of the
byval copy to the PTX calling convention.
The handling of these cases in the NVPTX backend for byval pointers has
some major issues. We currently attempt to determine if a copy is
necessary in NVPTXLowerArgs and either explicitly make an additional
copy in the IR, or insert "addrspacecast" to move the param to the param
address space. Unfortunately the criteria for determining which case is
possible are not correct, leading to miscompilations
(https://godbolt.org/z/Gq1fP7a3G). Further, the criteria for the
"simple" case aren't enforceable in LLVM IR across other transformations
and instruction selection, making deciding between the 2 cases in
NVPTXLowerArgs brittle and buggy.
This patch aims to fix these issues and improve address space related
optimization. In NVPTXLowerArgs, we conservatively assume that all
parameters will use the "move param" case and the local address space.
Responsibility for switching to the "simple" case is given to a new
MachineIR pass, NVPTXForwardParams, which runs once it has become clear
whether or not this is possible. This ensures that the correct address
space is known for the "move param" case allowing for optimization,
while still using the "simple" case where ever possible.
This patch adds initial vector extension support to RISC-V's exegesis.
The strategy here is to enumerate all RVV _pseudo_ opcodes as their MC
opcode counterparts are kind of useless under this circumstance. We also
enumerate all possible VTYPE operands in each CodeTemplate
configuration. Various of MachineFunction Passes are used for post
processing the snippets, like inserting VSETVLI instructions.
See https://llvm.org/devmtg/2024-10/slides/techtalk/Hsu-RVV-Exegesis.pdf
for more technical details.
and fix crash when vd_aux is invalid (#86611).
vd_version, vd_flags, vd_ndx, and vd_cnt in Elf{32,64}_Verdef are
16-bit. Change VerDef to use uint16_t instead.
vda_name specifies a NUL-terminated string. Update getVersionDefinitions
to remove some `.c_str()`.
Pull Request: https://github.com/llvm/llvm-project/pull/128434
We accidentally overwote the VL, VTYPE uses from the base class on any
instruction that also uses FRM.
Not sure why the llvm-mca test changed cycle time.
… memsz>0
Currently, segments with a file size of 0 are ignored for the purposes
of --change-section-lma, regardless of their memory size. It seems
reasonable to me to modify such segments given that we're changing the
LMA for all sections and these LMAs may be used during loading. GNU
objcopy also seems to adjust such segments.
Additionally, segments with file size > 0 and memory size = 0 will no
longer be modified for the purposes of --change-section-lma as they
shouldn't be part of the loaded memory image.
Fixes#124680
The numbers we previously picked for MicroOpBufferSize in both P400 and
P600's scheduling models turned out to be too conservative and didn't
properly reflect the characteristics of our microarchitectures. This
patch updates these numbers to be more faithful to our hardware.
This is unlikely to have any significant impact on MachineScheduler as
it only uses MicroOpBufferSize in few places. That said, it is supposed
to improve the accuracy of llvm-mca.
Let the actual syscall error if the file doesn't exist. This produces
a more standard "no such file or directory" phrasing of the error
message,
and avoids an extra step.
The same antipattern appears in the windows code, we should probably
fix that one too.
This commit creates an inconsistency on `__sanitizer_symbolize_pc` API. Before this change, this API always uses the filename from debug info when the line number is 0. After this change, the filename becomes invalid when line number is 0. The sanitizer might fall back to use base filename from symbol table. So, this API may return either `??:0` or `{filename from symbol table}:0` depending on if the symbol table has the filename for it. Make sure this inconsistency is resolved before relanding the commit.
The dynamic string table used by the dynamic section is referenced by
the sh_link field of that section, so we should use that directly,
rather than going via the dynamic symbol table.
More info:
https://github.com/llvm/llvm-project/pull/125679#discussion_r1961333454
Signed-off-by: Ruoyu Qiu <cabbaken@outlook.com>
This option prints the name of the DLL that gets imported, when linking
against an import library.
This is implemented using the same strategy as GNU dlltool does; looking
for the contents of .idata$6 or .idata$7 chunks. The right section name
to check for is chosen by identifying whether the library is GNU or LLVM
style. In the case of GNU import libraries, the DLL name is in an
.idata$7 chunk. However there are also other chunks with that section
name (for entries for the IAT or ILT); identify these by looking for
whether a chunk contains relocations.
Alternatively, one could also just look for .idata$2 chunks, look for
relocations at the right offset, and locate data at the symbol that the
relocation points at (which may be in the same or in another object
file).
When --check-globals none, we skipped all the globals in check lines.
However, we are still checking the meta info in function defintion.
The generated checks are still sensitive to metadata changes.
This is to scrub the meta info and match them with {{.*}} instead.
Looks like https://github.com/llvm/llvm-project/pull/124936 was reverted
(for modifying JSON output), but the test for JSON output with errors
was deleted in https://github.com/llvm/llvm-project/pull/126587 (to
attempt to fix failing build)
This will add back a test and a new one for llvm-dwarfdump to validate
the JSON for errors. One case where the sub-categories will eventually
appear and another where not.
test plan:
ninja check-llvm-tools-llvm-dwarfdump
Some of the functions in `#functions` may have several inlined
instances, but also an out-of-line definition.
Therefore, for complex enough DWARF input, `#functions` - `#inlined
functions` would not give us the number of out-of-line function
definitions.
`llvm-dwarfdump`, however, already keeps track of those; print it as
part of the statistics, as this number is useful in certain scenarios.
We add a generic out-of-order CPU model here just like what GCC
has done.
People may use this model to evaluate some optimizations, and more
importantly, people can use this model as a template to customize
their own CPU models.
The design (units, cycles, ...) of this model is random so don't
take it seriously.
[AMDGPU][NFC] Replace gfx940 and gfx941 with gfx942 in llvm/test
gfx940 and gfx941 are no longer supported. This is one of a series of PRs to remove them from the code base.
This PR uses gfx942 instead of gfx940 and gfx941 in the test RUN-lines (unless there is already a RUN-line for gfx942).
The only notable difference in the test output is that gfx942 does not force the use of sc0 and sc1 on stores while gfx940 and gfx941 do (cf. https://reviews.llvm.org/D149986).
For SWDEV-512631
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).
