Revert "[MC][TableGen] Expand Opcode field of MCInstrDesc" (#180321)
Reverts llvm/llvm-project#179652
This PR causes the out-of-memory build failures on many Windows
builders.
[mlir][Linalg] Promote lhs/rhs when vectorizing conv1D as outerproduct (#179883)
-- vector.outerproduct requires lhs/rhs to have same element type as the
result.
-- This commit adds a fix to promote lhs/rhs to have result's element
type when vectorizing conv1D slice to vector.outerproduct.
-- This is along the similar lines of what happens when we are
vectorizing conv1D slice to vector.contract - the corresponding
CHECK line was incorrect and this commit fixes that too.
Signed-off-by: Abhishek Varma <abhvarma at amd.com>
[SPIRV] Optimize getAllocatedType calls in LegalizeZeroSizeArrays (#179068)
Compute zero-sized allocation accurately using size APIs, and replace
them with 1 byte instead of 1 pointer of space.
Co-authored-by: Claude Sonnet 4.5 <noreply at anthropic.com>
[X86] AMD Zen 6 Initial enablement (#179150)
This patch adds initial support for AMD Zen 6 architecture (znver6):
- Added znver6 CPU target recognition in Clang and LLVM
- Updated compiler-rt CPU model detection for znver6
- Added znver6 to target parser and host CPU detection
- Added znver6 to various optimizer tests
znver6 features: FP16, AVXVNNIINT8, AVXNECONVERT, AVXIFMA (without BMM).
CodeGen, Driver: Add -fsanitize-trap-loop option.
This option may be used to opt into infinite loops for failed UBSan and
CFI checks. It causes Clang to generate an llvm.cond.loop intrinsic call
instead of a conditional branch to a trap instruction when generating
code for a conditional trap.
Part of this RFC:
https://discourse.llvm.org/t/rfc-optimizing-conditional-traps/89456
Reviewers: fmayer, vitalybuka
Reviewed By: vitalybuka, fmayer
Pull Request: https://github.com/llvm/llvm-project/pull/177688
Add llvm.cond.loop intrinsic.
The llvm.cond.loop intrinsic is semantically equivalent to a conditional
branch conditioned on ``pred`` to a basic block consisting only of an
unconditional branch to itself. Unlike such a branch, it is guaranteed
to use specific instructions. This allows an interrupt handler or
other introspection mechanism to straightforwardly detect whether
the program is currently spinning in the infinite loop and possibly
terminate the program if so. The intent is that this intrinsic may
be used as a more efficient alternative to a conditional branch to
a call to ``llvm.trap`` in circumstances where the loop detection
is guaranteed to be present. This construct has been experimentally
determined to be executed more efficiently (when the branch is not taken)
than a conditional branch to a trap instruction on AMD and older Intel
microarchitectures, and is also more code size efficient by avoiding the
need to emit a trap instruction and possibly a long branch instruction.
On i386 and x86_64, the infinite loop is guaranteed to consist of a short
conditional branch instruction that branches to itself. Specifically,
[9 lines not shown]
[MLIR][XeGPU] Propagate layout from anchor ops before Wg To Sg & Blocking Pass (#179490)
This PR calls recoverTemporaryLayout before the XeGPUWgtoSgDistribute &
XeGPUBlocking Pass to recover all the temporary operand layout which
might be required by the transformation patterns for checks and
verification
[CIR] Implement initial flattening of cleanup scope ops (#180063)
This implements flattening of `cir.cleanup.scope` operations that have a
single exit, and introduces checks to detect multiple exit cases and
report an error when they are encountered. At this point, only normal
cleanups are flattened. EH cleanup handling will be added in a future
change.
Substantial amounts of this PR were created using agentic AI tools, but
I have carefully reviewed the code, comments, and tests and made changes
as needed.
[libcxx] Rename `__split_buffer` alias template to `_SplitBuffer` (#180284)
`-Wchanges-meaning` is a GCC warning that catches shadowing in more
contexts. While a bit annoying here, it's a helpful warning. As such, we
need to rename the `__split_buffer` alias template in `std::vector` so
that we don't trip it up.
expose getObjCDirectMethodCallee for swift
Swift may need to emit calls to thunks as well. Instead
of letting swift rewrite the thunk generation logic, we
might as well expose the method.
[MLIR][XeGPU] Fixing PR179016 minor issues (#180295)
Fix two issues brough by PR179016:
1. unused variable if build the option with
"DLLVM_ENABLE_ASSERTIONS=OFF"
2. Recover modification to recoverTemporaryLayouts() brought by
PR176737. Unintentionally lost during the merging process.
[clang] Canonicalizing `-include-pch` input in the Frontend (#180065)
This patch adds logic to canonicalize `-include-pch`'s input in the
frontend. This way, the `ASTWriter` always serializes the canonicalized
path to the included pch file whether the input is an absolute path or a
relative path.
Fixes rdar://168596546.
[LifetimeSafety] Treat std::unique_ptr::release() as a move operation (#180230)
Add support for `std::unique_ptr::release()` in lifetime analysis to
avoid false positives when ownership is manually transferred via
`release()`.
- Added a new function `isUniquePtrRelease()` to detect when
`std::unique_ptr::release()` is called
- Modified `handleInvalidatingCall()` to mark the unique_ptr as moved
when release() is called
When manually transferring ownership using `std::unique_ptr::release()`,
the lifetime analysis would previously generate false positive
use-after-free warnings. This change treats `release()` as a move
operation, correctly modeling the ownership transfer semantics and
reducing false positives in code that manually manages ownership.
[Clang] Mark this pointer in destructors dead_on_return (#166276)
This helps to clean up any dead stores that come up at the end of the
destructor. The motivating example was a refactoring in libc++'s
basic_string implementation in 8dae17be2991cd7f0d7fd9aa5aecd064520a14f6
that added a zeroing store into the destructor, causing a large
performance regression on an internal workload. We also saw a ~0.2%
performance increase on an internal server workload when enabling this.
I also tested this against all of the non-flaky tests in our large C++
codebase and found a minimal number of issues that all happened to be in
user code.
