PTX with memory side effects (stores, atomics, mbarrier operations with
acquire/release semantics) emitted through `nvvm.inline_ptx` lowers to
`llvm.inline_asm` with register constraints only. Without a `~{memory}`
clobber, LLVM may reorder memory accesses across the inline assembly.
There was no way to express the clobber through this op or the
`BasicPtxBuilderInterface` machinery.
This patch adds, as discussed with @grypp:
- A `hasMemoryClobber` interface method (default `false`) on
`BasicPtxBuilderOpInterface`; when it returns `true`, `PtxBuilder`
appends `~{memory}` to the constraints of the generated inline assembly,
after all register constraints and tied indices.
- An opt-in `memory_clobber` boolean attribute (default `false`) on
`nvvm.inline_ptx` exposing this. Existing behavior is unchanged unless
the attribute is set to `true`.
For example:
```mlir
nvvm.inline_ptx "mbarrier.init.b64 [$0], $1;" ro(%p, %c : !llvm.ptr, i32) memory_clobber = true
```
now lowers to inline assembly with constraints `"l,r,~{memory}"`.
Tests: constraint emission with/without the attribute, combination with
predicate (`"l,r,b,~{memory}"`), read-write operands with tied indices
(`"=f,=f,r,r,0,1,~{memory}"`), and the no-operand case (`"~{memory}"`).
The op documentation's first example (mbarrier.init) is updated to show
correct usage.
FirstLoadableAddress was initialized with if (!FirstLoadableAddress), so
a valid first PT_LOAD at vaddr 0 was treated as unset and overwritten by
a later segment. Track whether the first loadable segment has been seen
instead.
Assisted by GPT-5
fillAMDGCNFeatureMap omitted mqsad-pk-insts for gfx1310/gfx13-generic,
so clang wrongly rejected __builtin_amdgcn_mqsad_pk_u16_u8 on those
targets even though the backend enables the feature. Add it to the gfx13 case.
Co-authored-by: Claude (Claude-Opus-4.8)
Currently the ordering of the parameters in `getEndPath` and
`finalizeVisitor` functions does not match the declaration of the
`VisitNode` function. This PR resolves it by reordering the parameters
among these functions to be consistent.
During the development of the lifetime checkers I had many important
test cases saved locally and were never imported to the test files of
the checkers. This PR adds those missing test cases to the test files.
By adding these test cases it helps tracking the state of the lifetime
checkers and what improvements they need in order to have better
coverage and reduce the false positive rate.
*AI policy*: During the development I have consulted with claude sonnet
5 to list me test case scenarios it thinks are useful and then reviewed
its feedback and implemented/wrote those test cases by myself. Since
some of the test cases are edge cases I wanted to make sure the
implementation is on the right track.
`leaveIntvAtTop` skips the target-specific block prologue when
determining the insertion point.
If the block prologue itself contains an instruction that interferes
with the interval, we must leave the interval before the block,
otherwise we will hit an assertion in `splitLiveThroughBlock`.
---------
Signed-off-by: Lukas Sommer <lukas.sommer@amd.com>
We sometimes see SCEV expansions like this:
%lshr = lshr i64 %n, 2
%shl = shl i64 %lshr, 2
which originate from SCEV mul and udiv expressions:
mul(4, udiv(%n, 4))
that both share the same multiplicand, divisor. The instcombine pass
normally canonicalises this into
%and = and %n, -4
which is the final IR typically seen by the backend. In the case of SCEV
expansion during a pass like the loop vectoriser, instcombine does clean
this up. However, before this is cleaned up it will lead to
over-estimation of costs of SCEV checks, since the shifts are costed
separately and added up. It doesn't seem like there is an easy way to
look at the use count of a SCEV node in the SCEVExpander code. However,
I think for simple cases like this it's always beneficial to fold them
even if there are multiple uses of the SCEV udiv because we're dropping
both shifts.
This shouldn't change anything semantically, only make the spec
(a) closer to the Vulkan spec, which includes reads in their location-ordered
relation: https://docs.vulkan.org/spec/latest/appendices/memorymodel.html#memory-model-location-ordered
(b) more uniform: this way, the may-see constraints are the same as the vanilla
LLVM constraints, only with all occurrences of "happens-before" replaced by
"location-ordered before".
`fir.select`, `fir.select_case`, `fir.select_rank`, and
`fir.select_type` are lowered to cf.* earlier in the pipeline
(`--fir-select-ops-conversion` and `--fir-polymorphic-op`). Their
FIR-to-LLVM conversion patterns are dead in a correct pipeline. Replace
them with a single templated stub
`SelectShouldHaveBeenConvertedStub<OP>` that emits `"'fir.<op>' op
should have already been converted"` and fails legalization, so running
`--fir-to-llvm-ir` standalone on stale IR reports a clear diagnostic
instead of "unable to legalize".
`Fir/convert-to-llvm.fir`'s six select* test blocks are removed (the
lowering no longer runs; CF-level coverage lives in
`Fir/SelectOpsConversion/`). `Fir/convert-to-llvm-invalid.fir` gains a
stub-error test per op. `Fir/Todo/select_case_with_character.fir` is
retargeted to check the equivalent diagnostic now emitted by
`--fir-select-ops-conversion`.
Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
PR Stack:
* https://github.com/llvm/llvm-project/pull/212977
* ▶️https://github.com/llvm/llvm-project/pull/212978
Co-authored-by: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
Always enable report_error_type=1 and print_summary=1 for CFI tests, and
update existing tests to check for cfi-bad-type. This allows us to
verify summary output comprehensively across the test suite.
This is a prerequisite for the change to the UBSan summary for CFI in
https://github.com/llvm/llvm-project/pull/203341.
Assisted-by: Automated tooling, human reviewed.
`X86TargetLowering::LowerFP_TO_INT_SAT` incorrectly lowered
`llvm.fptosi.sat.iN.f16` for N = 13, 14, 15, 16 under `avx512fp16`
codegen: NaN inputs produced the destination type's minimum value
instead of the 0 that the intrinsic's documented semantics require.
Vector forms that scalarize through this lowering are affected under
the same condition, applied per element. See the third commit message
for the full root-cause analysis and fix rationale.
---
Assisted-by: Claude (Anthropic)
Assisted-by: Codex (OpenAI)
The investigation, root-cause analysis, fix, and tests in this PR were
developed with substantial AI assistance (Claude), including four
independent AI-assisted review rounds (Codex). I reviewed and take
responsibility for all code, analysis, and claims in this PR, and can
answer questions about the reasoning above.
Fixes a Windows MSVC 2019-only build break from 02da012 ("TableGen: Use
a compact table for CPU aliases", #211952).
That commit added std::array<SubtargetSubTypeAliasKV, NumAliases> to
SubtargetSubTypeKVStorage. SubtargetSubTypeAliasKV uses relative string
offsets, so it is non-copyable and declares only a two-argument
constructor -
no default constructor. In the MSVC 2019 STL, std::array<T, 0> still
holds a
real _Ty _Elems[1] and value-initializes it, so it requires T to be
default-constructible. Any target that defines no ProcessorAlias records
instantiates std::array<..., 0> and fails to compile. MSVC 2022 changed
this
member to a conditionally-empty type, so only MSVC 2019 is affected.
Fix: add a constexpr default constructor.
Co-Authored-By: Claude Opus 5
Signed-off-by: Munoz Jr, Ramon <ramon.g.munoz.jr@intel.com>
A non-constant ObjC collection literal used as a file-scope initializer
should get the targeted err_objc_literal_nonconstant_at_file_scope
pointing at the offending element. CheckForConstantInitializer instead
inspected the wrapped Init/Culprit, so under -fobjc-arc, for id-typed
variables, or with parentheses it skipped the per-element loop and fell
back to the generic "initializer element is not a compile-time constant"
on the whole @{...}/@[...] -- or blamed the wrong element (e.g. a valid
string key rather than the non-constant value).
Unwrap the culprit with IgnoreParenImpCasts and drive classification and
per-element reporting off it, mirroring BuildObjC{Array,Dictionary}Literal
(unwrap before each isa<>; keys must be string literals, values/elements
constant object literals). Also treat CK_ARCReclaimReturnedObject as
transparent in Expr::isConstantInitializer so ARC-wrapped literals are
recognized and the reported culprit is the literal itself.
Add objc-constant-literal-dict-key-restrictions.m (macOS no-ARC, iOS ARC,
ObjC++), with each culprit on its own line so -verify checks the caret.
[Assisted-by](https://t.ly/Dkjjk): Opus 4.8
fillAMDGCNFeatureMap omitted atomic-fmin-fmax-global-f32 and
atomic-fmin-fmax-global-f64 for gfx1310/gfx13-generic, so clang wrongly
rejected the raw_ptr_buffer_atomic_f{min,max}_f{32,64} builtins on those
targets even though the backend enables the features. Add them to the
gfx13 case.
Co-authored-by: Claude (Claude-Opus-4.8)
Avoid generating ld4 when all values produced by the deinterleaved load
are fed into uitofp. Keeping the loads separate allows the backend to
optimize them into shifts and masks.
`DiagnosticErrorTrap::hasErrorOccurred()` treats warnings promoted to
errors by `-Werror` as real errors, causing `BuiltinDumpStructGenerator`
to bail out before building the `PseudoObjectExpr` wrapper. CodeGen then
encounters the untransformed `CallExpr` with a placeholder builtin type
and hits `llvm_unreachable` in `CodeGenTypes::ConvertType`.
Use `hasUnrecoverableErrorOccurred()` instead, which ignores `-Werror`
promoted warnings and only bails on genuine compilation errors.
Fixes#211943
Parsing cc1 command fails in `perf_helper` when `clang: note:` or
`clang: warning:` due to driver warnings. As an example, harmless macOS
sdk mismatch and `-Wunused-command-line-argument`.
Both headers were only included by their own `.cpp` file, so move the
class definitions into anonymous namespaces there and delete the
headers.
`getFromTypeWidthForLoad` was the only thing `NVPTXISelLowering.cpp`
needed from the ISel class, so it moves to `NVPTXUtilities` as a free
function.
The option was added by #211721 (sort forward thunks by descending
destination to prevent convergence failures) as a temporary opt-out.
Tests have been migrated to the default order.
Reverts llvm/llvm-project#204221 i.e., reapplies
https://github.com/llvm/llvm-project/pull/204197. The original patch was
reverted was due to a buildbot failure in vararg_shadow.cpp that relied
on undefined behavior as well as an unwarranted assumption that the
shadow is preserved when round-tripping from float->double->float. The
UB cases have been disabled in
https://github.com/llvm/llvm-project/pull/204246.
Original commit message:
The current instrumentation uses handleShadowOr(), which effectively
truncates or zero-extends the shadows for fptrunc/fpext respectively;
this is overly lax because floating-point has both mantissa and exponent
components (e.g., if the mantissa is initialized but the exponent is
uninitialized, an fptrunc might end up with a fully initialized shadow,
which is incorrect; conversely, if a floating-point value is fully
uninitialized, we want the fpext'ed shadow to be fully uninitialized,
not zero-extended). This patch strengthens the instrumentation of
fptrunc/fpext by using handleGenericVectorConvertIntrinsic(), which
applies an "all-or-nothing" approach to uninitialized bits of each
scalar.
Note: https://github.com/llvm/llvm-project/pull/203903 auto-upgraded
aarch64_neon_vcvtfp2hf and aarch64_neon_vcvthf2fp to fptrunc and fpext,
which had the effect of weakening MSan's instrumentation for those NEON
intrinsics. This patch restores the stronger instrumentation for them
(and also generalizes it to all instances of fptrunc and fpext).
This patch introduces SetVector::reserve to allocate capacity in the
underlying containers.
We also adopt SetVector::reserve across Attributor.cpp where the exact
number of unique functions being inserted is known ahead of time.
Assisted-by: Antigravity
Recast the RTBridge callers as templates parameterized on the call
signature, so future executor accessors can be added as thin
declarations rather than hand-written classes.
rt::Caller<RetT(ArgTs...)> is the runtime-agnostic caller interface for
a given signature, providing the asynchronous and synchronous call
operators and the associated result types. rt::MainCaller is now an
alias for rt::Caller<int64_t(ArrayRef<std::string>)>.
rt::sps::Caller<BaseT, SPSSigT, CIName> implements any such interface by
invoking an executor-side SPS wrapper in the runtime's controller
interface, deducing the argument and result types from BaseT. A concrete
caller is a typedef supplying the interface, its SPS signature, and the
CI entry-point name; see rt::sps::MainCaller.
MainCaller's observable behavior is unchanged (the existing
SPSCallersTest still passes). The out-of-line destructor anchor in
OrcRTBridge.cpp is dropped, as the templated base now provides an inline
defaulted destructor.
This PR adds an implementation of parallel
`std::lexicographical_compare()` based on parallel `std::mismatch()`.
The implementation is close to a one-liner:
```c++
auto __res = _Mismatch()(__policy, __first1, __last1, __first2, __last2, [&](_Ref1 __lhs, _Ref2 __rhs) {
return !__comp(__lhs, __rhs) && !__comp(__rhs, __lhs);
});
```
Included tests check that:
- Semantics of the iterator-only version is correct.
- Semantics of the predicated version is correct.
- The functions correctly SFINAE out when the first argument is not an
execution policy.
- The `noexcept` policy is followed.
- The `nodiscard` policy is followed.
- `static_assert` verifies iterators' categories.
Part of #99938.
fixes#186864
This is a more limited fix. that doesn't require us to change the whole
legalization strategy for SPIR-V.
To get the last fix to work it looks like I would have to have changed
every global opcode to no longer use power of 2 based legalization.
This change with power of 2 fixed the transpose case in the offload
testsuite when we do the conversion of bools to i32s before we call
transpose.
There remains an issue when a i1 makes it into a transpose intrinsic.
That said I can only trigger that case via llvmir and not HLSL so will
move on for now.
A diagnostics bundle records the state of the debugger, never what the
user was doing or what they expected instead, so reports arrive with a
generic title and no description of the problem. Pre-fill the report
with the questions only the person filing it can answer, and print a
checklist when the bundle is written so an incomplete report doesn't get
shared as-is.
rdar://183356348
This reapplies #207658.
Some targets do not support flang_rt or clang_rt.
It seems difficult to create a blocklist, so the tests are now
configured to explicitly specify the known-working targets.
The specified targets are extracted from tests in flang/test/Driver.
-----
The original commit message:
This patch intends to clarify the current behaviors, not to state the
expected/desirable behaviors.
PointerType and VPtrType have hard-coded sizes and alignments of 64/8
bits. On targets with 32-bit pointers (e.g., nvptx, spirv32), this trips
the record layout builder. Any record containing a pointer hit the
insertPadding assertion (offset >= size)
because the pointer was sized at 8 bytes while the following field was
placed at the AST-mandated 4-byte offset.
### Changes:
- CIRGenerator: attaches a CIR-native cir.ptr data-layout entry at
module setup, storing {size-in-bits, abi-align-in-bits} read
from the target DataLayout (only for the default address space).
- CIRTypes: PointerType reads its size/alignment from that entry
(falling back to 64/8 when absent); VPtrType routes through a cir.ptr so
it picks up the same width.
- LowerToLLVM: strips the cir.ptr entry during CIR→LLVM lowering, since
cir.ptr has no meaning in LLVM IR.
- Unit test: checking 4-byte pointer/vptr layout on nvptx, verified
across CIR, CIR→LLVM.
The answer isn't right and the wrong type might stick and cause
downstream failures.
Note, the correct solution to this is to distinguish between "couldn't
get the address" and "got a real value of LLDB_INVALID_ADDRESS" but
piping an optional all the way down and then through all the uses is an
intrusive change which I don't have time for right now. That only risk
is that this really IS a tagged pointer with the value
LLDB_INVALID_ADDRESS, so this seems an acceptable workaround.
I ran across this when debugging the ObjC test failures in the ObjC
testuite after 8b9cce358b. This patch
clears up all those testsuite failures, which should stand as a test for
this patch when I resubmit that change.
This implements the basics, and leaves NYI in a few places (particularly
those that require cleanup calculations). There IS some additional work
that needs to be done when the ABI work is put in place as well, and the
thunk 'tail' hint isn't implemented either, and is left as a
missing-feature.
This is necessary for compiling the bytecode interpreter in Clang in a
few places during self-build.
