Resolves#194415
- A constructor specifically meant for `optional<T&>` was left enabled
for `optional<T>`
- Fix it, and add a test to check for regression.
- This patch also corrects the constraints for `optional(optional<U>&)`
and `optional(const optional<U>&)` , as they were incorrectly
disallowing [valid conversions](https://godbolt.org/z/1r5Ea7z5M)
- Also, correct the `noexcept` specification.
- Add tests for both corrections.
(cherry picked from commit 239189ca28)
Some VPlan transforms, like vectorizing fmin without fast-math,
introduce AnyOfs, which have costs assigned in the VPlan-based cost
model, but not the legacy cost model. Account for their cost like done
for other similar VPInstrctions, like EVL.
Fixes https://github.com/llvm/llvm-project/issues/185867.
(cherry picked from commit 475cc4fe0b)
[ Upstream commit 589faedadf ]
Revert `bltu` in probing loops to `blt` because commit
f162be2486 isn't applied on release/22.x
yet.
Link: https://github.com/llvm/llvm-project/pull/192485 ("[RISCV] Use
unsigned comparison for stack clash probing loop")
---
This PR adds a call to `inlineStackProbe` immediately after
`allocateStack` in `eliminateCallFramePseudoInstr`. This allows code
generation for stack probe pseudoinstructions in non-entry BBs.
Fixes#195454.
foldToMaskedStore (added in
1c0ac80d4a)
rewrites
store(vselect(cond, x, load(ptr)), ptr) -> masked_store(x, ptr, cond)
passing the vselect condition straight through as the store mask. A
masked
store follows the IR convention of a vXi1 mask, but the condition can be
a
wider boolean vector. On AVX512F targets without VLX, a maxnum/minnum
store-back lowers the NaN test with a legacy packed (CMPP) comparison
whose
result is a vXi32/vXi64 vector, so the masked store is created with a
wide
mask and LowerMSTORE asserts:
Assertion `Mask.getSimpleValueType().getScalarType() == MVT::i1 &&
"Unexpected mask type"' failed.
When the matching vXi1 type is legal, narrow the mask to it before
building
the masked store. Targets where vXi1 is illegal (e.g. AVX/AVX2) keep the
wide
mask and continue to lower it as a blend/vmaskmov, and targets whose
vselect
condition is already vXi1 (e.g. AArch64 SVE, RISC-V RVV) are unaffected.
This fixes the crash at the source and lets the X86 LowerMSTORE keep its
invariant of only ever seeing a vXi1 mask (no target-specific
workaround).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
(cherry picked from commit e6bd788707)
On the "main" branch, Symbol no longer has the `used` member which was
moved in PR #190117 (commit 6a874161). Therefore, when the cherry pick
from PR #198129 (commit 905a88b9) was merged to the "release/22.x"
branch, the initialization of `used` was lost.
All of i64, f64, v2i32, v4i16, v8i8 are assigned to the DoubleRegs
register class (64-bit register pairs). A bitcast between any two of
these types is a machine-level no-op (ie. the same physical register is
reinterpreted with a different type).
HexagonPatterns.td had NopCast_pat entries for all int-to-int bitcasts
within DoubleRegs, and explicit patterns for f64 <-> i64, but was
missing patterns for f64 <-> v2i32, f64 <-> v4i16, and f64 <-> v8i8. The
same gap existed in IntRegs for f32 <-> v2i16 and f32 <-> v4i8.
Without a tableGen pattern for "f64 = bitcast v2i32" node, the
instruction selector crashed with:
LLVM ERROR: Cannot select: t26: f64 = bitcast t6
t6: v2i32,ch = CopyFromReg t0, Register:v2i32 %2
Fix by adding the five missing NopCast_pat entries.
Fixes: https://github.com/llvm/llvm-project/issues/195495
(cherry picked from commit c005f737e7)
Building with --fat-lto-objects was added in #140381 (cff9ae7a15). On
macOS the tests are failing when building release binaries with many
"The file was not recognized as a valid object file" errors, e.g.:
2026-01-16T12:54:26.0928880Z
/Users/runner/work/llvm-project/llvm-project/build/tools/clang/stage2-instrumented-bins/tools/clang/stage2-bins/_CPack_Packages/Darwin/TXZ/LLVM-22.1.0-rc1-macOS-ARM64/bin/llvm-strip:
error:
'/Users/runner/work/llvm-project/llvm-project/build/tools/clang/stage2-instrumented-bins/tools/clang/stage2-bins/_CPack_Packages/Darwin/TXZ/LLVM-22.1.0-rc1-macOS-ARM64/lib/libLLVMAArch64AsmParser.a(AArch64AsmParser.cpp.o)':
The file was not recognized as a valid object file
It's assuming bitcode is embedded in section .llvm.lto
(llvm/lib/Object/ObjectFile.cpp:80) but on MachO it's in
__LLVM,__bitcode (llvm/lib/Object/MachOObjectFile.cpp:2184)
llvm-bitcode-strip is a driver for the MachO bitcode_strip utility which
handles this. Use this instead.
Fixes#176398.
Assisted-by: codex
(cherry picked from commit b8e768f6ae)
They were sometimes incorrect because the written type doesn't contain
an NNS which contains template parameters we're interested in.
No release note because the bug broke MS STL and I want to backport it
to the last 22.x release
Fixes https://github.com/llvm/llvm-project/issues/198663
(cherry picked from commit 06ffb65590)
WebAssemblyLateEHPrepare::addCatchRefsAndThrowRefs was using
Catch->getIterator()->getNextNode() to find the insertion position
after the CATCH (or CATCH_ALL) instruction in an EH pad.
If the CATCH/CATCH_ALL instruction is the last instruction in the basic
block, getNextNode() returns nullptr, which causees a crash when passed
to BuildMI. This patch fixes it by using std::next(Catch->getIterator())
which returns MBB.end() if the catch is the last instruction, and the
overload of BuildMI that takes an iterator correctly handles BB.end().
Fixes#197077
Assisted-By: Gemini
(cherry picked from commit dc40fccbc1)
When combineCCMask is called on a TM node with two constant operands,
and all of the bits in the mask are active, the existing APInt bit
access goes off the overall length of the integer by one. This commit
fixes that by using the index value of the leftmost active bit, rather
than the number of active bits.
(cherry picked from commit 78eca55b54)
According to [associative.reqmts] `extract(k)` returns the _first_
element in the container with key equivalent to k.
(cherry picked from commit 72871f6fa1)
Just like for PAGEBASE_REL21, the immediate in SECREL_HIGH12A is the
byte offset, not a page offset. The byte level offset is added to the
symbol offset, which only then after that gets shifted right by 12. This
makes the handling of this immediate consistent with what MS link.exe
does.
The existing testcase had a zero immediate in the instruction for this
relocation.
This makes it clear that immediate offsets with SECREL_HIGH12A do work
fine, where the byte level offsets end up carrying over to the upper
bits.
(cherry picked from commit 5c95f6a859)
When lowering an i64 load in LowerINT_TO_FP, we were forwarding the
original !range metadata to a new f64 load. This is invalid because the
metadata no longer matches the value type/semantics, and can trigger
assertions when lowering i64 to fp (double or float) conversions.
This patch fixes this by passing a nullptr for the Ranges operand when
calling getLoad() and adds extra test cases to cover signed/unsigned i64
to f32/f64 conversions and to ensure they do not assert when the !range
metadata is present.
The assertion this patch attempts to fix is:
```
Assertion failed: (!MMO->getRanges() || (mdconst::extract<ConstantInt>(MMO->getRanges()->getOperand(0)) ->getBitWidth() == MemVT.getScalarSizeInBits() && MemVT.isInteger())) && "Range metadata and load type must match!"
```
This assert was originally seen when building Rust on AIX.
(cherry picked from commit 78f5f7717a)
Shuffle combining fails to fold the inner shuffles first, but luckily the LanePermuteAnd* methods are enough if we have VPERMB as a fallback
Fixes#137422
(cherry picked from commit 1b9fea0218)
The combine introduced in 55aff64d2c
lowers scalar i128 compares into vector compares by reissuing the
original loads as v16i8 loads. However, the combine was reusing the
original MachineMemOperand without modification.
If the original i128 load carries !range metadata, the MMO encodes that
range using i128 values. Reusing this MMO for a v16i8 load is incorrect
as range metadata is only valid for integer scalar types and its
bitwidth must match the memory VT.
This patch fixes this by creating a new MachineMemOperand for the vector
vector load. Additionally, we restrict the combine for constant operands
to avoid cases that are better handled by scalar lowering. Small
constants (fit within 16 bits) are excluded to prevent generating
suboptimal vector compares.
(cherry picked from commit 1907b58638)
Ensure that use of the GNU driver does not change the library name on
Windows. We would check the build tools being MSVC rather than targeting
Windows to select the output name.
(cherry picked from commit 687e66c989)
Summary:
This check exists to encode the policy that this is only intended to be
built with a just-built compiler. In practice it's a little too strict
and breaks pretty much every six months when the version bumps or when
people try to build a separate patch. Just demote to a warning.
(cherry picked from commit 13da33e922)
`initSectionsAndLocalSyms` and `makeDefined` memset the storage to zero
and then placement-new a Symbol-derived object into it. Placement new
begins a new object's lifetime. The standard does not seem to guarantee
the memset bytes carry into members the constructor leaves
uninitialized.
lld built by GCC 16 can make Valgrind report reads of Symbol::flags
(via getSymSectionIndex during finalizeSections) as uses of
uninitialized values (ClangBuiltLinux/linux#2162).
This patch reinstates the per-field initialization that commit
7787427605 ("[ELF] Avoid redundant assignment to Symbol fields. NFC")
had replaced with a bulk memset.
(cherry picked from commit 905a88b923)
Close https://github.com/llvm/llvm-project/issues/190333
For the test case, the root cause of the problem is, the compiler
thought the declaration of `operator &&` in consumer.cpp may change the
meaning of '&&' in the requrie clause of `F::operator()`. But it doesn't
make sense. Here we skip profiling the callee to solve the problem. Note
that we've already record the kind of the operator. So '&&' and '||'
won't be confused.
---
See the discussion in https://github.com/llvm/llvm-project/pull/194283
For the new found pattern that we may have other binary operator (e.g.,
operator +) in the require clause, e.g.,
```C++
template <typename T, typename U>
requires requires(T t, U u) { t + u; }
void operator()(T, U) {}
```
This is a new problem and we need to solve it in other PR.
(cherry picked from commit 2751c7ed06)
Windows EH requires exception objects allocated on stack. But there is
no reliable way to identify them. CoroSplit employs a best-effort
algorithm to determine whether allocas persist on the stack or the
frame, which may result in miscompilation when Windows exceptions are
used.
This patch proposes that we treat allocas used by catchpad as exception
objects and never place them on the frame. A verifier check is added to
enforce that operands of catchpad are either constants or allocas.
Close#143235Close#153949Close#182584
Fixes issue: https://github.com/llvm/llvm-project/issues/192351
The combination of coroutines with -fextend-variable-liveness has
resulted in use-after-free, caused by the fact that we insert fake uses
of coroutine parameters at the end of the coroutine. While this is fine
for normal functions, in coroutines these variables are stored in the
coroutine frame, which is freed before the end of the function; this
results in us loading from the deleted frame.
This patch fixes this by no longer emitting fake uses for most coroutine
parameters. Since coroutine parameters will be saved back to the frame
when we suspend, and currently may not be optimized out, fake uses are
not needed in this case, and so by not emitting them we avoid dealing
with the complexity of updating fake uses in the CoroSplit pass. The
exception to this is 'this', which is not saved to the frame.
(cherry picked from commit efb01c1bf5)
```
// a.cc
static void foo(int x) {
switch (x) {
#define GENERIC(n) case n:
#include "types.def" // -isystem header invokes a user macro
break;
}
}
// sys/types.def
#define MID(name) GENERIC(name)
MID(0)
MID(1)
MID(2)
```
```
$ clang -fprofile-instr-generate -fcoverage-mapping -isystem sys -c a.cc
Assertion `SystemHeadersCoverage ||
!SM.isInSystemHeader(SM.getSpellingLoc(Loc))' failed.
```
Commit 702a2b627f ("[Coverage] Rework !SystemHeadersCoverage")
replaced the system-header skip in gatherFileIDs with this assertion,
which trips as `SM.isInSystemHeader(SM.getSpellingLoc(Loc))` is false.
This patch adds back the pre-#91446 condition but folds it with
the macro-token remap `if` statement.
Fixes #179316/#195422.
Clang Opus 4.7 identified clang/lib/Parse/ParseExpr.cpp, created a
minimal reproduce with cvise, and wrote the initial version of this
CodeGen patch. (An earlier session papered over the bug by patching
llvm-cov instead, which I abandoned).
(cherry picked from commit 10f941727f)
`SoftPromoteHalfOperand` had no case for `ISD::BR_CC`, causing a crash
when a half-typed `fcmp` result fed directly into a conditional branch.
All other comparison-related nodes (`SETCC, SELECT_CC`) were already
handled. Add `SoftPromoteHalfOp_BR_CC` following the same pattern as
`SoftPromoteHalfOp_SELECT_CC`.
Fixes#195562
---------
Co-authored-by: Tony Varghese <tony.varghese@ibm.com>
(cherry picked from commit 6da957d8cb)
The special treatment of single-element 128-bit vector types in
SystemZTargetLowering::getRegisterTypeForCallingConv is not appropriate
if vector types are not supported, and can lead to internal compiler
errors.
Fixes: https://github.com/llvm/llvm-project/issues/194256
(cherry picked from commit 48346f2352)
On Windows, file descriptors are only valid in the same DLL: they are
really just handles mapped to an index in a table in the CRT. Calling a
liblldb method with a file descriptor from lldb-dap will cause the
program to crash. See
https://github.com/llvm/llvm-project/issues/193971.
This patch fixes the issue by refactoring the `NativeFile` constructors
so that they no longer try to convert `FILE` types to handles through
the CRT lookup table.
(cherry picked from commit 176dff4a5a)
This cache file can be used to build a multi-target cross Windows/Linux
to ARM/Aarch64/etc. Linux toolchain.
[Replacement for CrossWinToARMLinux.cmake on the buildbot]
(cherry picked from commit bfe80fb3bb)
A function like
```llvm
define <4 x i16> @xtn_shuffle_even_v8i16(<8 x i16> %a) {
entry:
%r = shufflevector <8 x i16> %a, <8 x i16> poison, <4 x i32> <i32 0, i32 2, i32 4, i32 6>
ret <4 x i16> %r
}
```
will use the `xtn` instruction, which for each 32-bit vector element
keeps only the lower 16 bits, so effectively this is a truncation.
However, if the vector actually has 16-bit elements, then the conversion
from a shuffle to a truncation is only valid on LE, not on BE. On BE,
`uzp1` should be used instead. So this PR moves some logic to right
after a check for LE, so that BE does not miscompile.
I filed this as an issue on `rust-lang-rust` as
https://github.com/rust-lang/rust/issues/155459, and we had some
discussion at [#t-libs/stdarch > `simd_shuffle!` behaves
strangely on
`aarch64_be`](https://rust-lang.zulipchat.com/#narrow/channel/208962-t-libs.2Fstdarch/topic/.60simd_shuffle.21.60.20behaves.20strangely.20on.20.60aarch64_be.60/with/587766433).
Under certain conditions the LLVM `MipsDelaySlotFiller` fills a branch
delay slot with an instruction requiring a load delay slot. However the
`MipsDelaySlotFiller` does not check the filled instruction for hazard
which leads to code like this:
```asm
beqz $1, $BB0_5
lbu $2, %lo(_RNvCs5jWYnRsDZoD_3app13CONTROLLERS_A)($2)
# --- Some other instructions
$BB0_5:
andi $1, $2, 1
```
`lbu` got moved into the branch delay slot but has a load delay slot -
so when jumping to `$BB0_5` the value for `$2` will not be ready, which
leads to undefined behavior.
This PR suggests to declare instructions with a load delay slot to be
hazardous for the branch delay slot, only for `MIPS1`. This will prevent
the load instructions in the branch delay slot, which has a slight
impact on the optimization.
Ideally in case of a load instruction in a branch delay slot, we would
want to check the target register and check if it is used in the
following instruction and at the branch destination instruction. Code
for this is already in place from a previous PR (`bool
MipsInstrInfo::SafeInLoadDelaySlot(const MachineInstr &MIInSlot, const
MachineInstr &LoadMI) const`), however I'm not experienced enough with
the LLVM to identify the `MachineInstr` required for that ideal
situation.
If I could get some feedback about this I might be able to stitch it in.
The original issue came from Rust and is described [here rust issue
150676](https://github.com/rust-lang/rust/issues/150676). It was then
raised in the LLVM project [here issue
180639](https://github.com/llvm/llvm-project/issues/180639#issuecomment-3874380424)
and in the forum
[here](https://discourse.llvm.org/t/where-to-start-fixing-an-opt-pass-for-mips1/89857).
Co-authored-by: Jaby <jaby@william.zone>
(cherry picked from commit 458e9c452c)
The implicit contract of an `LF_BUILDINFO` record (represented in LLVM
by
[`BuildInfoRecord`](6f0b55ec55/llvm/include/llvm/DebugInfo/CodeView/TypeRecord.h (L667)))
is that its `CommandLine` field should not contain the input source file
— a separate `SourceFile` field is reserved for that.
When the command-line flattening was moved from `llvm/` to `clang/` in
#106369, the comparison value used to identify and strip the source
positional was switched from `MainSourceFile->getFilename()` (the full
input path resolved by clang) to `CodeGenOpts.MainFileName` (just the
basename, set via `-main-file-name`). As a result, when the driver is
invoked with an absolute source path the cc1 positional is that absolute
path and no longer matches `MainFileName`, so the source filename leaks
into `CommandLine` as a trailing positional cc1 argument.
This is a regression in Clang 20. It breaks downstream tooling such as
Live++, whose unity-splitting feature relies on the embedded command
line being the cc1 invocation minus the source. Reported in #193900.
This PR restores the previous behavior by passing the resolved frontend
input path(s) to `flattenClangCommandLine` and including them in the
equality check that strips the source positional. The basename match
against `MainFileName` is kept for the relative-input case. A regression
test (and a symmetric relative-path test) is added to
`clang/test/DebugInfo/Generic/codeview-buildinfo.c`.
Should fix#193900.
(cherry picked from commit 27ebc844f5)
```
llvm-cov export /tmp/Cov/bin/lld -instr-profile=/tmp/Cov/cov.profdata -format=lcov --sources lld/ELF/Arch/RISCV.cpp
```
does not finish after minutes.
Root cause: The expansion-region count propagation loop is bounded by
`VirtualFileMapping.size()`, the number of macro expansions.
In the TableGen-generated `RISCVGenDAGISel.inc` (depended on by
LLVMLTO), `NumFileMappings` is 74941 (largely due to the `TARGET_VAL`
macro). With 149887 mapping regions, the loop does not finish after more
than ten minutes.
Fix with an early break.
(cherry picked from commit 0135cf99f3)
After #180322, X86 FastISel forces SDAG fallback for any call with a
struct return. This caused major compile-time regressions for debug
builds in Rust, where struct returns are very common.
The type legality check should work on the de-aggregated types, not on
the return type directly.
(cherry picked from commit 30fa4153a5)
The addition of the support for `--enable-non-contiguous-regions` from
PR #90007 moved an "early out" condition in
`LinkerScript::computeInputSections()`. This could result in other
relatively expensive checks, i.e. `pat.sectionPat.match`,
`cmd->matchesFile`, `pat.excludesFile` and `flagsMatch`, to be performed
unnecessarily in the default situation where
`--enable-non-contiguous-regions` is disabled.
This fix restores the "early out" condition and shows an ~14%
improvement for the Linux kernel benchmark link and has been seen to
improve performance by up to ~30% for a large UE5 link.
(cherry picked from commit dbdbf1e63d)
A dependent member-pointer type doesn't necessarily have a class
declaration.
This simplifies the check performed in a helper for diagnosing a cast
which removes qualifiers, so it doesn't rely on this assumption.
This fixes a regression introduced in
https://github.com/llvm/llvm-project/pull/132401, which landed in the
last release, and this will be back ported, so no release notes.
Fixes#194524
(cherry picked from commit c147ccadae)
This PR enables the option `-fpatchable-function-entry` for SystemZ. It
utilizes existing common code and just adds the emission of nops after
the function label in the backend.
SystemZ provides multiple nop options of varying length, making the
semantics of this option somewhat ambiguous. In order to align with what
`gcc` does with that same option, we#re choosing `nopr` as the
canoonical nop for this purpose.
For test, this adapts an existing test file from aarch64.
(cherry picked from commit 355898a6ce)
If we have 2 or more undef/undemanded elements, the INSERTPS replaces
those with explicit zero'd elements which can cause infinite loops later
on in shuffle combining depending on whether we demand those elements or
not.
I'll try to improve the (minor) v2f32 regressions in a follow up, but I
need to fix the infinite loop first.
Fixes#186403
#194110
Linux Kernel has removed scc.h header completely from the source code
Therefore, we need to remove the usage in compiler-rt/sanitizer too.
64edfa6506 (diff-1ca78e598a5041ee51ae795d168435afad598b82a7a0ce80f215993589b96c7c)
Without removing it, not only it breaks compiler-rt but also GCC build
since GCC always builds libsanitizer for linux targets.
After merging this we will need to cherry pick to GCC.
(cherry picked from commit 3dc4fd6dd4)
This patch adds a new ModuleOwnershipKind::VisiblePromoted to handle
declarations that are not visible to the current TU but are promoted to
be visible to avoid re-parsing.
Originally we set the visible visiblity directly in such cases. But
https://github.com/llvm/llvm-project/issues/188853 shows such decls may
be excluded later if we import #include and then import. So we have to
introduce a new visibility to express the intention that the visibility
of the decl is intentionally promoted.
Close https://github.com/llvm/llvm-project/issues/188853
(cherry picked from commit c97e08e331)
