[DWP] Eagerly clear buffers after writing (#213345)
Lowers peak memory usage on a llvm-dwp invocation from 12.37GB ->
11.19GB.
This actually now beats out GNU dwp (11.35GB) at least when the output
file is in tmpfs.
[flang][OpenMP] Diagnose failed construct decomposition instead of falling through (#214012)
`buildConstructQueue` asserts that decomposition produced output:
```cpp
ConstructDecomposition decompose(modOp, semaCtx, eval, compound, clauses);
assert(!decompose.output.empty() && "Construct decomposition failed");
```
Release builds have no check, so the empty queue falls through to the
loop below and out to the
caller. That is undefined behaviour, and it is reachable — semantics
does not catch every
directive/clause combination that cannot be decomposed. The result is an
intermittent segfault
rather than a diagnostic.
#211430 is one way in: `allocate` is an OpenMP 5.0 clause, but most
directives declare it in
[45 lines not shown]
[SystemZ][z/OS] Add guard for SI_USER (#213101)
SI_USER is not defined on z/OS and is causing the following build
failure. `error: use of undeclared identifier 'SI_USER'`
This patch adds a guard to check whether SI_USER is defined
before using it.
[TableGen][AsmMatcher] Resolve RegClassByHwMode kinds for all operands
validateOperandClass() only remapped a RegClassByHwMode operand kind
when the actual parsed operand was a register. When the operand was
something else entirely (e.g. a bare immediate where a register was
expected), this fell through to the generic "Kind <= MCK_LAST_REGISTER"
diagnostic check, so we end up with a generic Match_InvalidOperand.
No test changes here, but this is needed to avoid diagnostic regressions
with the RVY load/store support (PR #177073).
Pull Request: https://github.com/llvm/llvm-project/pull/213479
[TableGen] Generate `getRegClassFromMatchKind()` for AsmMatchers
This helper can be useful in validateTargetOperandClass to get the
MCRegisterClass for the MCK_* enum.
Migrate the RVY logic to use this new generated function. Checking all
register classes instead of just the RVY ones will marginally slow down
validateTargetOperandClass, but since this is already a slow path it
should not matter.
If multiple RegisterOperands share a ParserMatchClass but map to different
RegisterClasses, omit them from the generated getRegClassFromMatchKind
mapping function. I originally tried to emit an error here, but it turns
out there are many targets that rely on sharing the ParserMatchClass with
different (but similar) RegisterClasses so ignoring them is safer.
Reviewed By: lenary
Pull Request: https://github.com/llvm/llvm-project/pull/200453
[SystemZ][z/OS] use LLVM_THREAD_LOCAL instead of thread_local (#214039)
This patch is to fix the following error on z/OS
```
llvm/include/llvm/Support/PerThreadBumpPtrAllocator.h:75:12: error: thread-local storage is not supported for the current target
75 | static thread_local std::vector<AllocatorTy *> Cache;
| ^
```
[AMDGPU][GISel] Add RegBankLegalize rules for amdgcn_tanh
Enable the existing gfx1250 and gfx13 GlobalISel coverage now that tanh operands are assigned to VGPRs.
Co-authored-by: Cursor <cursoragent at cursor.com>
[AMDGPU][GlobalISel] Legalize BF16 fneg and fabs
Restore the BF16 semantic types omitted by the extended LLT migration and preserve packed vector legalization.
Co-authored-by: Cursor <cursoragent at cursor.com>
[clang][DependencyScanning] Dissolve DependencyScannerImpl.h/cpp (#211409)
`DependencyScannerImpl.h/cpp` were created to share code between TU
scanning and by-name scanning when they were on different code paths.
After unifying the implementation through `CompilerInstanceWithContext`,
we no longer need a separate header/cpp pair and all the code are moved
into `DependencyScanningWorker.cpp`. This PR is mechnical and does not
intend to introduce behavivor changes.
---
<sub>Stack created with <a
href="https://github.com/github/gh-stack">GitHub Stacks CLI</a> • <a
href="https://gh.io/stacks-feedback">Give Feedback 💬</a></sub>
[clang][DependencyScanning] Use CompilerInstanceWithContext for TU Scanning (#211408)
After `CompilerInstanceWithContext`'s relocation to
`DependencyScanningWorker.cpp`, we can use it freely as an
implementation engine for TU scanning. This PR does that, and unifies
the by-name scanning and TU scanning so they all go through
`CompilerInstanceWithContext`.
rdar://167034309
---
<sub>Stack created with <a
href="https://github.com/github/gh-stack">GitHub Stacks CLI</a> • <a
href="https://gh.io/stacks-feedback">Give Feedback 💬</a></sub>
[llvm-objcopy] Add AMDGPU case to binary-output-target.test
Add test coverage for converting binary input to elf64-amdgpu format,
verifying the output has the correct format string, arch (amdgpu),
and machine type (EM_AMDGPU 0xE0). Follows the same pattern as all
other architectures in this test file.
[llvm-objcopy] Fix AMDGPU arch string in test: amdgpu not amdgcn
llvm-readobj reports 'Arch: amdgpu' for EM_AMDGPU ELF files
(the generic AMDGPU ELF format used by elf64-amdgpu). The test
was incorrectly expecting 'amdgcn', which is the AMDGCN-specific
arch string used by ROCm HSA code objects.
[llvm-objcopy] Address reviewer feedback on AMDGPU test cleanups
- Remove unused -DMACHINE yaml2obj template variable in cross-arch-headers.test,
hardcode Machine: EM_NONE directly in the YAML instead
- Remove unused Flags: [[FLAGS=<none>]] template variable in cross-arch-headers.test
- Add comment in binary-output-target.test explaining that Arch: unknown is
intentional when converting from binary (e_flags=0, no EF_AMDGPU_MACH set)
[llvm-objcopy] Address review feedback for AMDGPU test in cross-arch-headers
Per reviewer feedback, use the existing non-AMDGPU input (%t.o, EM_NONE)
to test conversion to elf64-amdgpu. This properly demonstrates that
--output-format changes the machine type, consistent with all other cases
in this test file.
The output reports Arch: unknown because converting from a non-AMDGPU ELF
produces e_flags=0 (no EF_AMDGPU_MACH set); added a comment explaining
this. Flag control is a separate concern for a follow-on PR.
[llvm-objcopy] Fix AMDGPU arch checks in tests
ELFObjectFile.h getArch() for EM_AMDGPU returns Triple::UnknownArch
when e_flags & EF_AMDGPU_MACH is 0 (no GPU target specified). Only
when a MACH flag in the AMDGCN range is present does it return
Triple::amdgpu.
- cross-arch-headers.test: restore EF_AMDGPU_MACH_AMDGCN_GFX900 flag
on the input ELF so that after format conversion the output correctly
reports Arch: amdgpu.
- binary-output-target.test: expect Arch: unknown since converting
from raw binary input (-I binary) produces an ELF with e_flags=0
(no MACH flags), giving UnknownArch. This is correct behavior.
DDT: Make ddt_zap_walk() use cursor _by_dnode functions
ddt_zap_walk() already receives dnode as an argument. We can save
one dnode_hold() per entry by using _by_dnode cursor functions.
zap_cursor_init_noprefetch_by_dnode() is added in the process.
Signed-off-by: Alexander Motin <alexander.motin at TrueNAS.com>
Reviewed-by: Rob Norris <rob.norris at truenas.com>
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Closes #18888
