[NVPTX] Add native `tanh.approx` support for f16/f16x2/bf16/bf16x2 (#203257)
Adds NVPTX backend support for the native PTX `tanh.approx` instructions on half-precision and bfloat types:
- `tanh.approx.f16` and `tanh.approx.f16x2` (PTX 7.0+, sm_75+)
- `tanh.approx.bf16` and `tanh.approx.bf16x2` (PTX 7.8+, sm_90+)
Adds a `FTANHInst` TableGen class with the new patterns in NVPTXInstrInfo.td and splits `ISD::FTANH` out of the unconditional `f16/bf16 -> f32` promotion loop in NVPTXISelLowering.cpp, marking it Legal when the target supports it (scalars promote, vectors expand on older targets). Also guards `tanh.approx.f32` behind sm_75 and adds the
missing `AddPromotedToType` for bf16.
PTX Spec Reference:
https://docs.nvidia.com/cuda/parallel-thread-execution/#half-precision-floating-point-instructions-tanh
Signed-off-by: Varad Rahul Kamthe <vkamthe at nvidia.com>
[SelectionDAG] Widen even 33-bit-magic udiv on free-zext targets (#207634)
On 64-bit targets, #181288 lowers a 32-bit unsigned division by a
constant with a 33-bit magic number (the `IsAdd` case) to a widened
64-bit high-multiply (`MULHU`/`UMUL_LOHI`), e.g. `x / 7` becomes a
single `mulq`/`umulh`/`mulhu`. That only reaches odd divisors. This
patch extends it to even divisors on targets where the `i32 -> i64`
zero-extension is free.
[AMDGPU] Clean up GFX13 feature list
GFX13 features were previously mostly inherited from GFX12/GFX1250.
- define an explicit gfx13 target parser feature list, including
gfx13-insts and cvt-pknorm-vop3-insts.
- remove transpose load F4/F6 support from gfx13 (previously copied from gfx12)
[VPlan] Add VPInstruction::Intrinsic opcode, use for scalar intrinsics. (#207541)
This patch adds a new Intrinsic opcode to VPInstruction, initially used
for generating calls to scalar intrinsics. The intrinsic ID as integer
is the last operand (i.e. the called function). Alternatively we could
also create the needed intrinsic declarations and pass the function
directly, but that would add potentially unused declarations, if we
decide to not vectorize.
The first patch migrates just VScale, but there are other opcodes
matching directly to intrinsics, which will be replaced in follow ups.
It also gives more flexibility going forward, e.g. allows emitting
min/max intrinsics when expanding SCEV min/max expressions.
PR: https://github.com/llvm/llvm-project/pull/207541
[flang][Driver] Add option for real sum reassociation (#207377)
Compiler driver option for #207371: -freal-sum-reassociation.
Disabled by default.
Assisted-by: Codex
[AArch64] Add missing TB(N)Z achors to arith+CBZ clustering (#207725)
This patch adds missing TBZ+TBNZ anchors for arith+CBZ clustering. They
have similar nature to CBZ as specific kinds of it, so this patch
classifies them under the same subtarget feature name compactly. This is
better for Apple CPU. They can be reasonably expected to behave
similarly on AArch64 targets.
[RISCV] Adjust max stack-threshold on 64bit systems (#208223)
Shouldn't emit [-Wframe-larger-than] warning on 64-bit systems, when
stack-size is greater than UINT32_MAX (the previous default). Update the
maximum stack-size-threshold on 64-bit systems to INT64_MAX.
NOTE: GCC has both rv32/rv64 thresholds set to the respective signed
maximum unlike LLVM.
[Offload] Make compressed offload bundle header little-endian
The compressed offload bundle (CCOB) header integer fields (Magic,
Version, Method, FileSize, UncompressedFileSize, Hash) were serialized
and read in host-native byte order. The on-disk format is little-endian,
so on big-endian hosts these fields were byte-swapped: writing produced a
malformed header and reading misparsed the size, making
llvm-objdump --offloading crash/misbehave on s390x.
Use support::ulittleN_t for the header fields on the read side and
support::endian::Writer on the write side, so the header is always
little-endian regardless of host endianness.
Co-authored-by: Nikita Popov <npopov at redhat.com>
Revert "[Object] Disable test on big endian (#205999)"
This reverts commit f6cc23dda19d5e0aab0a8946e6e9242992428b4e.
The compressed offload bundle header is now serialized and parsed as
little-endian regardless of host endianness (see the parent commit), so
fatbin-coff-compress.test no longer needs the host-byteorder-little-endian
guard and can run on big-endian hosts again.
Reland [llvm] Errorize DebuginfodFetcher for inspection at call-sites (#194872)
Failure to fetch debuginfod is rarely an error, but there are case where
we want to distinguish error reasons down the line, for example in order
to test connection timeouts.
[AArch64] fix 128-bit Sequentially Consistent load (#206936)
Emit 128-bit SC loads the way that the AArch64 atomics ABI requires, by
introducing an LDAR before the LDP. See atomicsabi64.pdf at
https://github.com/ARM-software/abi-aa/releases.
[libc++] Remove some unnecessary functions from __vector_layout (#207152)
This removes functions which produce identical IR after the first
InstCombine pass after inlining compared to their replacements.
[clang] Reject 'auto' storage class with type specifier in C++ (#166004)
Fixes #164273
---------
Signed-off-by: Osama Abdelkader <osama.abdelkader at gmail.com>
[clang] [serialization] Step into UsingShadowDecl when find existing decl (#208393)
Close https://github.com/llvm/llvm-project/issues/207581
The root cause of the problem is that：enum constant decl, for which its
parent is not enum class, is special. They can be accessed directly
without access its parent. When modules join the game, it becomes more
complex. As for members in other entities like class, we can assume the
member is accessable if their parent are accesable. But it is a
different story for enums. See
https://github.com/llvm/llvm-project/issues/131058 for the whole story
of the backrgound.
Then we didn't write enum constant decl to the lookup table of its
parent of parent in the ASTWriter. So that if other consumer in Sema
wants to access them, they have to get it by entities like exported
using decls. However, the problem is, in ASTReader, when we merge decls,
we use noload_lookup to find existing decls. And the absense of unnamed
enum decl in the parent of its parent's lookup table makes the merge
[7 lines not shown]
[dsymutil] Use DWARFDie::getLanguage instead of manually finding DW_AT_language (#208174)
With DWARFv6, CUs may not have a `DW_AT_language` (but a
`DW_AT_language_name` instead). In
https://github.com/llvm/llvm-project/pull/207151 we made
`DWARFDie::getLanguage` account for this possibility. However, dsymutil
explicitly tries to find `DW_AT_language` in several places.
This patch ensures we go through `DWARFDie::getLanguage` instead in most
of them.
The only way I found this to be testable/observable is by testing the
`isODRLanguage` code paths. Added a test that exercises this.
There is one remaining use of `DW_AT_language` in
`DependencyTracker.cpp`. But was going to address that in a separate
change.
AI usage:
- Test written with the help of Claude
[ObjectYAML] Fix issues found in review of #207306 (#208160)
- checkLimit(): avoid uint64_t overflow.
- writeAsBinary(): check the limit against the bytes actually written.
- updateDataAt(): take const void *Data.
Revert "[IR][NFC] Drop vtable from PassConcept/PassModel" (#208389)
Breaks ASan builds due to new-delete mismatch.
Closes #208381.
Reverts llvm/llvm-project#208168
[AArch64][FastISel] Update arm64-fast-isel-int-ext.ll check lines (NFC) (#207996)
Similar to #207159 (merged as 15b3882), update the CHECK lines
automatically in prep for new tests and bug fixes.
Require GraphHasNodeNumbers in llvm::LoopInfoBase; drop the DenseMap fallback (#207905)
LoopInfoBase kept a DenseMap fallback for block types whose GraphTraits
has no getNumber() (std::conditional_t on GraphHasNodeNumbers). With the
last such in-tree users now numbered (mlir::Block #207617 and BOLT's
BinaryBasicBlock #207899), require GraphHasNodeNumbers via static_assert
and make BBMap unconditionally a SmallVector indexed by block number,
dropping the DenseMap branch in
getLoopFor/changeLoopFor/removeBlock/analyze/verify.
Aided by Claude Opus 4.8
[Clang][AMDGPU] Add amdgcn_av("none") attribute for atomic expressions
Add a statement attribute that suppresses MakeAvailable/MakeVisible
cache operations on AMDGPU atomic instructions while preserving memory
ordering (waits).
The attribute takes a string argument specifying the mode. Currently
"none" is the only supported mode. The resulting atomic or fence
instruction carries !mmra !{!"amdgcn-av", !"none"} metadata.
Support includes C/C++ atomic builtins, _Atomic type qualifier
operations, fence builtins, and AMDGPU-specific atomic builtins
marked with TargetAtomicMixin.
Uses Builtin::Context::isTargetAtomicBuiltin() to identify
target-specific atomic builtins in target-neutral Sema code.
Assisted-By: Claude Opus 4.6
[orc-rt] Move the regression tests into test/regression (#208391)
Move the regression lit config and the existing tests into
test/regression/, and point the check-orc-rt suite there.
This is a first step towards consolidating tests and test infrastructure
under orc-rt/test. Upcoming commits will add a test tools directory, and
move the existing unit tests (under orc-rt/unittests) into
orc-rt/test/unit.
[AArch64] Expand FORM_TRANSPOSED_REG_TUPLE to copies before regalloc (#207205)
Previously, we kept the FORM_TRANSPOSED_REG_TUPLE nodes around during
register allocation. The problem with this approach is that it does not
model the potential overlap in live ranges between the destination and
source operands.
As a result, the register allocator assumes it has complete freedom to
allocate registers to the operands. For example, there is nothing
stopping it from allocating:
```
{z0, z1, z2, z3} = FORM_TRANSPOSED_X4 z3, z2, z1, z0
```
However, such cases are hard to expand later, either requiring spills or
complex shuffles. The current expansions of FORM_TRANSPOSED_REG_TUPLE
miscompile in cases like this because, when naively expanded into copies
after register allocation, earlier copies can clobber values that are
still needed by later ones.
[31 lines not shown]
[FIRToMemRef] Fix wrong indexing for converted array_coor over sliced fir.embox (#207749)
FIRToMemRef::convertArrayCoorOp routes through getMemrefIndices, which
only folds the first `rank` triples of sliceInfo.sliceVec into the
memref indices (i.e. the array_coor's own slice); the embox's slice
triples -- which sit at [rank*3 .. 2*rank*3-1] when both are present --
were dropped. Three consequences, three fixes here:
1. Non-collapsed embox slice lbs contribute (lb - 1) per Fortran dim to
each memref index. Fold them in in memref order (reversed Fortran order)
so the reinterpret_cast view lands at the right column.
2. The shapeVec-else stride path used shapeVec[0..rank-1] to build the
outer strides. With both slices present, that's the box's (slice's)
extents. Use shapeVec[rank..2*rank-1] instead -- the parent's extents --
so the outer stride is the parent's leading dim rather than the slice's
own size.
3. Rank-reducing embox slices (undef ub/step triples) have no memref
[6 lines not shown]
