This reverts commit 42eb7db188f23625872b6f1d722979a3100d170e. This
reland 3fbb037d03e7ff1ef1cd9156363e895af7caaf98 (#209922).
Under CMake 4+, calling add_library(... SHARED IMPORTED) on a target
platform that lacks dynamic linking support triggers a fatal error. This
becomes an issue when building LLVM and runtimes for baremetal targets
like armv6m-none-eabi. This patch adds the option
"LLVM_OMIT_EXPORTS_FROM_CONFIG" in LLVM. When used in sub builds like
LLVM runtimes, it makes CMake to skip including the LLVM and Clang
exports. This mitigates the CMake 4 errors on baremetal runtimes.
42eb7db188f23625872b6f1d722979a3100d170e originally
apply this flag on all runtimes build and causing issues on runtimes
like intel-sycl-gpu, amdgpu-offload-ubuntu-22-cmake-build-only.
This PR only set this flag when the target platform lacks shared library
support.
(cherry picked from a04f87fdd9b59c6089bf731c669c6f149208363c and
91406e8dff2b1578ff4dd22593ea1a8039b074a4)
[RISCV] Reduce spill/reload pairs when Xqcilo extension is enabled
Currently, `SelectAddrRegImm26` calls `SelectAddrFrameIndex` first,
causing bare frame-index loads (offset 0) to select 48-bit loads/stores at
ISel. Due to `AddedComplexity=2` on the QC48LdPat patterns, the wide
opcode won over the standard LW/SW even though the resolved frame offset
typically fits simm12.
This led to more spills and reloads in functions which are under high
register pressure because 48-bit loads and stores are not marked easily
rematerializable. Also, simply adding 48-bit loads and stores to
`isLoadFromStackSlot/isStoreToStackSlot` doesn't solve the regression
for the multi call case and only by making Isel produce the plain
32/64-bit loads and store opcodes as the baseline does RA behave
identically.
Therefor this PR fixes the issue by:
-Remove the `SelectAddrFrameIndex` call from SelectAddrRegImm26. Bare frame
indices now fall through to standard LW/SW selection at ISel, where RA
recognizes them as rematerializable stack loads.
-Add post-RA promotion in `eliminateFrameIndex`: when a plain LW/SW has a
resolved frame offset that exceeds simm12, promote the opcode to
the corresponding 48-bit load/store opcode and fold the 26-bit offset
directly. This preserves the intended large-offset optimization
without affecting RA decisions.
This solves the code size regression in high register pressure function
introduced by PR #209315
Assisted by Claude
(cherry picked from commit 8b18aa0b1ec2de76d47748a4d13c4de02b4d8580)
A function that saves a callee-saved EGPR (R16-R31) cannot be encoded with V1/V2 unwind info, so it must use V3 even when the module default stays on V1/V2 (e.g. an APX clone created by auto-dispatch alongside a baseline generic clone). The previous code rejected such functions with a recoverable backend diagnostic ("EGPR (R16-R31) requires V3 unwind info on Windows x64") instead of emitting valid V3 unwind info.
Introduce a single shared predicate, requiresWinX64UnwindV3(MF), that returns true when the whole module is in V3 mode, or when the function needs an unwind table and may use EGPR. It is consumed by X86FrameLowering (SEH prolog/epilog layout), the X86WinEHUnwindV2 pass (which skips such functions), and the X86WinEHUnwindV3 pass (which stamps a per-function .seh_unwindversion 3 on every WinEH frame -- the entry block and each funclet). Also widen the SEH_UnwindVersion pseudo operand from i1imm to i8imm since it holds 1, 2 or 3.
(cherry picked from commit 9466be2c87689a07c9a171f24cb5c9b0c2f0cda8)
InstCombine pull request
https://github.com/llvm/llvm-project/pull/194519 canonicalized the
saturating negation idiom to
an llvm.ssub.sat operation. For the ARM backend we only recognized the
original
select and subtract pattern, causing vector absolute values to expand to
VQSUB
plus a compare and select instead of VQABS.
In this patch we teach the VQABS and VQNEG patterns to recognize this
ssub.sat
form.
(cherry picked from commit c99e6752b9f9e1867af88c07ee44f837bc6e4311)
`clang++` defaults to `-stdlib=libc++` on NetBSD. When building with
both `clang` and `libcxx` included, the freshly built `clang++` fails to
find `<__config_site>`:
```
In file included from /usr/include/strings.h:68:
In file included from bin/../include/c++/v1/string.h:57:
bin/../include/c++/v1/__config:13:10: fatal
error: '__config_site' file not found
13 | #include <__config_site>
| ^~~~~~~~~~~~~~~
```
The file is present in `include/<triplet>/c++/v1`, but that isn't
searched by default. NetBSD has its own version of addLibCxxIncludePaths
which misses that directory.
This patch removes `NetBSD::addLibCxxIncludePaths` in favour of the
generic version in `Gnu.cpp`. The current code also adds
`/usr/include/c++`, although this directory only contains empty
directories in a default installation. It is only used when a bundled
version of LLVM is installed, which is not usually the case, and even
then contains a static version of `__config_site` that only applies to
`libcxxrt`.
Tested on `amd64-pc-netbsd10.1`, `x86_64-pc-solaris2.11`,
`x86_64-pc-linux-gnu`, and `x86_64-pc-freebsd15.1`.
(cherry picked from commit 9a19c7750f949c979372ba1d2eec8a7a40061aef)
On ARM64X targets, CRT provides separate TLS directory chunks, expecting
the linker to sort it out. TLS directory uses _tls_start and _tls_end
symbols to reference .tls section. Those symbols use section sorting to
ensure that they are emitted at the start and end of .tls section, but that's
not enough when we have two separate chunks for views: only one of them
can really be the first one. Following MSVC, merge those chunks instead so
that both symbol tables point to the same chunk.
Additionally apply the same logic to _tls_used and _tls_index. This
allows entire TLS directory to be shared between EC and native views. To
achieve that, CRT additionally needs to mark each TLS callback with
-arm64xsameaddress. This matches how MSVC linker and libraries work, but
it requires EC and native views to use the same set of TLS callbacks. We
may emit separate TLS directories in the future to make it more robust.
(cherry picked from commit e096d2f60dbc6cab991d5c02a5f7125a6dc694dc)
As mentioned in #205562, there are cases where the transformation stage
in LoopInterchange stops partway through, and the output IR ends up
partially modified rather than interchanged. Notably, the interchange is
recognized as having succeeded internally even in such cases. Apparently
this happens not to cause any miscompiles at the moment, but it is
clearly dangerous.
This patch removes the early exit in the transformation phase. We cannot
simply remove it, which checks for the presence of a unique successor of
the inner loop header, because there is a case where the header actually
has multiple successors. To avoid that situation, this patch changes the
code to call SplitBlock on the inner loop header unconditionally.
The test changes fall into two categories: some are simply due to newly
added redundant BBs. In the others, the expected interchanges are now
applied as intended, whereas previously the transformation failed and
the interchanges were not applied before this patch.
(cherry picked from commit ca52c1b3abbadf829598872b7dded2bca2fd50c0)
It crashes because the `default` error string may not be a format string
compared to the `fallback` error string
(cherry picked from commit 29bc0749034c4f2bda0752360ecacd4e89d7439c)
The lack of those is causing instruction selection to fail.
Also, for completeness, add variants of extending/truncating ops for
LOAD-BSWAP pairs too.
(cherry picked from commit 7afc89970fc3675d77e92aa091b65c078cacdcff)
This is the only job that actually needs to use the environment secrets,
so the environment must be declared. We were using secrets in the
prepare job to do a permissions check, but this is unnecessary, because
that job does not do anything that is security sensitive.
Only the upload job needs to have these permission checks and these are
already included in the upload-release-artifact composite action.
(cherry picked from commit 02bde0716776a742164941e05cb026e750763b04)
Compiler-synthesized functions such as `__llvm_gcov_writeout`,
`__llvm_gcov_reset` and `__llvm_gcov_init` were previously never
receiving the AArch64 hardening function attributes (ptrauth-returns,
ptrauth-auth-traps, ptrauth-indirect-gotos and
aarch64-jump-table-hardening) since the attributes were only emitted by
Clang and gated by `PointerAuthOptions` structure's corresponding
fields. See `setPointerAuthFnAttributes` and
`initPointerAuthFnAttributes` member functions of `TargetCodeGenInfo`.
This patch resolves this in the same manner as #83153 does for several
other attributes. Particularly, Clang now emits corresponding 4 module
flags (conditionally on whether the related feature is enabled) with Max
behavior, and LLVM's `Function::createWithDefaultAttr` derives the
matching function attributes from them. Max behavior with conditional
emission is safe because none of these features affect ABI, so promoting
an absent flag on module merge cannot break compatibility.
(cherry picked from commit 2f8eb5b4be3eba5c7f58470d6538d00df53a55fc)
This is the sibling patch of #207254, as it turns out VECTOR_INTERLEAVE
has the same problem on fixed vectors as well.
Instead of converting individual operands into scalable vectors, this
patch puts each of the operands directly onto stack using the fixed
vector version of segmented store intrinsics, before loading them back.
---------
Co-authored-by: Luke Lau <luke@igalia.com>
(cherry picked from commit ff9b99207b5d4ec73554defc1e3c1ac50f8ff1d8)
Swift allows functions inside enums:
enum Foo: Int {
case bar = 0
func baz() { ... }
}
DW_TAG_enumeration_type "Foo"
DW_TAG_enumerator "bar"
DW_TAG_subprogram "baz" DW_AT_declaration
...
DW_TAG_subprogram DW_AT_low_pc(...) DW_AT_specification -> "baz"
dieNeedsChildrenToBeMeaningful() did not list DW_TAG_enumeration_type,
so the parent walk skipped the enum's children.
Assisted-by: claude
rdar://183549452
(cherry picked from commit ade128740327db281859708ddcb3b072903b3414)
Common globals were not emitted in GOFF object files due to a missing
emitCommonSymbol implementation. This adds the implementation to emit
the required SD/ED/PR ESD records in the GOFF object file.
(cherry picked from commit 705d0ec6115cef3232eafe6221f42f78e7b884e8)
Deleting the temporary files produced by the DTLTO pipeline can be
expensive on Windows hosts. For a Clang link (Debug build with
sanitizers and instrumentation) using an optimized toolchain (PGO
non-LTO, llvmorg-22.1.0) on a Windows 11 Pro (Build 26200), AMD Family
25 @ ~4.5 GHz, 16 cores/32 threads, 64 GB RAM machine, the mean duration
of the "Remove DTLTO temporary files" time trace scope was 1267.789 ms
(measured over 10 runs).
This patch performs the deletions on a background thread, allowing them
to overlap with the tail of the link to hide this cost.
This is a re-implementation of the asynchronous cleanup idea from
https://github.com/llvm/llvm-project/pull/186988, which had to be
reverted in https://github.com/llvm/llvm-project/pull/189043 because
cleanup was not guaranteed to complete before LLD invoked
timeTraceProfilerCleanup(). In certain cases timeTraceProfilerCleanup()
was called before temporary file deletion had completed in LLD, which
caused memory leaks that were flagged by sanitizer builds.
Note that the DTLTO implementation has been refactored heavily since
https://github.com/llvm/llvm-project/pull/186988, so this is a
re-implementation along the same lines.
To solve the ordering issue, LLD now calls a hook that defaults to a
no-op, and DTLTO overrides it to drain the background deletion work.
LLD calls this hook before time-trace write/cleanup.
(cherry picked from commit 914d5a1841dedf2148e21bd6de3b92409fe79285)
Sema::UnusedLocalTypedefNameCandidates is populated while iterating a Scope's
DeclsInScope, which is a SmallPtrSet whose iteration order depends on pointer
values and is therefore not stable across runs. The candidates are serialized
into the AST file -- both to assign declaration IDs and to write the
UNUSED_LOCAL_TYPEDEF_NAME_CANDIDATES record -- and are also used to emit the
deferred -Wunused-local-typedef warnings, so neither the emitted PCH/AST file
nor the diagnostics were reproducible. With deterministic compilation caching
this surfaces as a "cache poisoned" error, because two builds of the same PCH
produce different bytes.
Sort the candidates by source location at the point they are consumed, via
Sema::getSortedUnusedLocalTypedefNameCandidates(), so that both the diagnostics
and the serialized declarations are deterministic.
Selects of floats carry fast-math flags. Update getDefaultFlags to take
the result type and use it to handle selects. I am planning on extending
this to other similar opcodes, including PHIs.
Then update sinkPredicatedStores to pass through the correct default
flags.
This fixes a crash in cse when intersecting common metadata.
Fixes https://github.com/llvm/llvm-project/issues/212811.
PR: https://github.com/llvm/llvm-project/pull/212973
(cherry picked from commit 40e33eb35417f565e2ed8a6c0dba63cbd618a926)
This patch fixes the remaining compile errors when running `ninja
check-all` on FreeBSD and NetBSD:
- `sanitizer_linux.cpp` doesn't compile on NetBSD, so this patch adds a
cast:
```
sanitizer_common/sanitizer_linux.cpp:2492:10: error: format specifies
type 'unsigned long long' but the argument has type '__greg_t' (aka
'unsigned long') [-Werror,-Wformat]
```
- `tsan_interface_atomic.cpp` doesn't compile on both FreeBSD and
NetBSD, so this patch disables the warning:
```
tsan_interface_atomic.cpp:353:12: error: unused function template
'NoTsanAtomic' [-Werror,-Wunused-template]
tsan_interface_atomic.cpp:358:12: error: unused function template
'Atomic' [-Werror,-Wunused-template]
tsan_interface_atomic.cpp:389:12: error: unused function template
'NoTsanAtomic' [-Werror,-Wunused-template]
tsan_interface_atomic.cpp:394:12: error: unused function template
'Atomic' [-Werror,-Wunused-template]
tsan_interface_atomic.cpp:401:12: error: unused function template
'NoTsanAtomic' [-Werror,-Wunused-template]
tsan_interface_atomic.cpp:406:12: error: unused function template
'Atomic' [-Werror,-Wunused-template]
```
- `sanitizer_linux_libcdep.cpp` doesn't compile on NetBSD:
```
sanitizer_linux_libcdep.cpp:527:27: error: use of undeclared identifier
'__lwp_getprivate_fast'; did you mean '_lwp_getprivate'?
```
This is the same issue already handled in `tsan_platform_linux.cpp`: to
expose the `__lwp_getprivate_fast` definition in `<machine/mcontext.h>`,
`_RTLD_SOURCE` needs to be defined before `<machine/mcontext.h>` is
included (indirectly from `<signal.h>` in this case). It also needs to
include `<sys/types.h>` to get a definition of the `__aligned` macro.
Tested on `amd64-pc-freebsd15.1` and `amd64-pc-netbsd10.1`.
(cherry picked from commit 6e92d6d0577cbe102bd48f396301ea5cd0ebf247)
Fixes#212993#194729 made the m_Select a m_SelectLike, so FindLastSelect could now be
a blend. However we were checking the first operand to see if the Cond
needed inverted. A select has `select %cond, %true, %false`, a blend is
`blend %false, %cond, %true`, so we were failing to negate the
condition.
(cherry picked from commit 4f705acc388ab2c627fb263d89d1d60468f8a97b)
`getConstant()` recognizes an AVL that is an immediate by checking
the opcode is `ADDI`, then reading the second operand and checking
if it is `X0`. However the second operand may be a frame index and
`getReg()` asserts with "This is not a register operand!".
We should guard the register access with `isReg()` before comparing
against `X0`.
Fixes#212797.
(cherry picked from commit ef7f2f611993a4bc59e181d2bf8fc6269d7e1c7d)
The .reloc branch in emitMachineConstantPoolValue fired for any
isWeakForLinker() + isDSOLocal() symbol, including TLS (thread_local)
weak symbols. R_ARM_REL32 is wrong for TLS: TLS symbols need
TLS-specific relocations (R_ARM_TLS_GD32 etc.). Using R_ARM_REL32 for a
TLS symbol produces a wrong address at runtime.
This broke the 2-stage ARM 32-bit buildbots: stage 1 (with the .reloc
branch) miscompiled stage 2's BPF codegen (BTFDebug.cpp references
llvm::sys::sandbox::Enabled, an inline thread_local weak variable),
causing a SIGSEGV in the BPF Assembly Printer.
Add a regression test (tls_weak_var in elf-preemption.ll) verifying that
TLS weak symbols get TLSGD/TPOFF, not R_ARM_REL32.
Fix#212545
(cherry picked from commit f4382bedc245a22ea7c354d08eb13543166a5f0d)
Update the applySubstitutions call in `libcxx/utils/libcxx/test/format.py` to match the
change to `llvm/utils/lit/lit/TestRunner.py` done in 1041a9642b.
(cherry picked from commit a8617034c4a7cc733676a31b736d3118fec34259)
If we eliminate an `undef` copy and there is a use of the copy that
`isDef` on just a sub-register, mark it as `undef`.
Fixes#204036.
(cherry picked from commit c85d1c54c5fba6344b117e369328a4b9b5a1386b)
On x86_64-windows-msvc after 8ecec45518, clang applies the MSVC
size-based global-alignment scheme (Microsoft64BitMinGlobalAlign) and
does not apply the Sys V "large array" alignment increase. Users may
want to preserve the earlier ABI for compatibility with objects produced
by older clang releases.
Gate this behavior on the Clang ABI compatibility level. When
`-fclang-abi-compat=22` (or lower) is in effect,
MicrosoftX86_64TargetInfo restores LargeArrayMinWidth/LargeArrayAlign to
128 and getMinGlobalAlign skips the Microsoft64BitMinGlobalAlign step,
matching the older alignment choices.
Assisted by Claude (Anthropic).
(cherry picked from commit cb383a37440d27238f8a01eee05228910d65d63e)
Reverts llvm/llvm-project#186093
Issue https://github.com/llvm/llvm-project/issues/206839 shows that
EliminateSpillageCopies is not currently ready to be enabled by default
on AArch64. https://github.com/llvm/llvm-project/pull/207169 was raised
to fix the issue, but concerns were raised around complexity of the
function and change. Until a suitable solution can be found,
EliminateSpillageCopy will be disabled on AArch64 by default.
For those who wish to still use the pass, `-enable-spill-copy-elim=true`
will ensure the pass is run.
(cherry picked from commit debd8a7f889b29551dff7897f807e17f90eeee1d)
Add support for lowering masked loads/stores of <4 x bf16> and <8 x
bf16> when target features contain "+sve" and "+bf16".
Fixes: #201149
(cherry picked from commit b9869c8c920a7dfa983e215bc30729b13d8b353b)
Similar to #208744, this makes sure that bf16 masked gather and scatter
work with fixed-length sve enabled. Without +bf16 the operations are
currently expanded pre-isel, but that will not be fixed in this patch as
it is a larger change and this patch is intended to be ported to the
branch.
(cherry picked from commit 32221d9ff8f4772972193ebf7b8ba4974cd8458f)
A fixed-length `llvm.vector.partial.reduce.add` reducing `<16 x i8>`
into `<2 x i64>` is lowered on `+sve` by converting the reduction to a
scalable one and finishing with `convertFromScalableVector`. The i8 ->
i64 fold splits the `(nx)v4i32` dot before converting it back to fixed
length, but splitting a scalable container is not equivalent to
splitting the fixed vector it holds: at vscale=2 an `nxv4i32` container
splits into two `nxv2i32`, each holding four i32s, not the two-lane
halves of the underlying `v4i32`. The high partial sums land in lanes
that `convertFromScalableVector` then discards, so any runtime VL > 128
silently drops them — on a 256-bit machine (e.g. Neoverse V1) exactly
half the result is lost (#204939; downstream miscompile
rust-lang/rust#158144).
Convert the dot back to a fixed-length i32 vector before splitting, so
the split, widen and accumulate all happen in fixed length and no lanes
are dropped. The fixed dot width is derived from the result (two i32
lanes per i64 result lane) so the wider, VL-pinned `<4 x i64> <- <32 x
i8>` reduction — which also reaches this fold on plain SVE — lowers
correctly. This is the i64 sibling of the `v16i8 -> v2i32` case fixed in
#177119 (issue #176954); the fixed-length support was introduced in
#142032.
(cherry picked from commit bad9ad339743d262793c15fddfab90bd976e531b)
Foundation's small value inline representations have valid summaries and
sometimed synthetic children, but LLDB cannot access any ivars from
their base classes (such as [NSObject isa]).
Use a synthetic child provider to hide them.
rdar://182434208
Assisted-by: claude
(cherry picked from commit 4f02e1e45c2711a94dae0eac2051ad7c2e5ca8c2)
Guard hasTagDefinition() against invalid type-specifier state so
recovery from invalid auto/tag combinations does not assert.
Fixes#210014
---------
Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
(cherry picked from commit de4b1f5572f8ff5a38a17655584ae200774551c6)
We always selected crt1.o as the CRT start file, regardless of link
mode.
Select rcrt1.o - the self-relocating static-PIE start file when -static
and PIE are active
(cherry picked from commit c45b4e4d00bed488d6ece5608560561732ae5b9e)
COMPILER_RT_INSTALL_LIBRARY_DIR must be CACHE STRING, not CACHE PATH: a
relative PATH-typed cache entry resolves against the runtimes sub-build
directory instead of CMAKE_INSTALL_PREFIX, misplacing sanitizer libs.
Replace the explicit COMPILER_RT_BUILD_* ON list with
COMPILER_RT_SANITIZERS_TO_BUILD=all, since those options already default
ON upstream and infeasible sanitizers self-exclude via their own
ALL_<X>_SUPPORTED_ARCH lists.
Add FORCE to the dylib overrides so they take effect after
hexagon-unknown-linux-musl-clang-dist.cmake has already cached them OFF.
(cherry picked from commit 34aefe9744fa83fa222d7f28e073c693c2c4ff5b)
RISCVInstrInfo::isSafeToMove scans the instructions between From and To
to decide whether a memory instruction can be moved, but it only treated
mayStore() instructions as barriers. Calls on RISC-V are modeled with
isCall() and a register mask rather than mayStore(), so a load could be
moved across a call even though the callee may clobber the loaded
memory.
RISCVVectorPeephole::foldVMergeToMask uses this helper via ensureDominates()
to sink a load into a masked load when folding it into a vmerge, which
produced wrong code when the load was sunk past a call.
Instead of hand-rolling the barrier check, call MachineInstr::isSafeToMove
on each intervening instruction to populate SawStore. That is the same
helper used on From below, and it already treats calls (as well as PHIs
and ordered memory references) as stores.
This fixes#212226.
Assisted-by: TRAE CLI (DeepSeek V4 Pro)
(cherry picked from commit 840060f2f85c2d3f8ebe1c9304770d682e4141f6)
`test_release.sh` tries to build `openmp` as a project, which breaks the
build:
```
CMake Error at CMakeLists.txt:155 (message):
Support for the LLVM_ENABLE_PROJECTS=openmp build mode has been removed.
Please switch to the bootstrapping build
cmake -S <llvm-project>/llvm -B build -DLLVM_ENABLE_PROJECTS=clang -DLLVM_ENABLE_RUNTIMES=openmp
or to the runtimes default build
cmake -S <llvm-project>/runtimes -B build -DLLVM_ENABLE_RUNTIMES=openmp
```
This patch switches it to a runtime to match.
Tested on `x86_64-pc-linux-gnu`.
(cherry picked from commit f91647a732298131e86fc4f465b20b80105f35d6)
Haowei
Tom Stellard
Garvit Gupta
Feng Zou
Ties Stuij
Nikolas Klauser
Rainer Orth
Jacek Caban
Ryotaro Kasuga
Ebuka Ezike
Koakuma
Daniil Kovalev
Min-Yih Hsu
Augusto Noronha
Paschalis Mpeis
Maryam Moghadas
Slava Zakharin
Ben Dunbobbin
Steven Wu
Florian Hahn
Luke Lau
Marina Taylor
Pengcheng Wang
yingopq
dong jianqiang
Hubert Tong
Matt Arsenault
Ajay Wakodikar
Nathan Ridge
Ryan Buchner
Evgenii Kudriashov
Jack Styles
Shanzhi Chen
David Green
Matthew Blewitt
Adrian Prantl
Osama Abdelkader
Brian Cain
Nerixyz
Anatoly Trosinenko
Tobias Hieta