[CHERI][RISCV][MC] Add shared support for aligning globals to an "alignment granule", which is applied to both the alignment and the allocated size. (#203872)
On CHERI targets, bounds are generally stored in a compressed format
which imposes alignment requirements based on allocation size. When
emitting globals, we need to align and tail-pad them as appropriate to
ensure that the pointer to the global will have bounds that are precise,
i.e. not covering any non-padding bytes that either precede or follow
While this patch adds the plumbing necessary to support this feature on
arbitrary targets, it only concretely implements it for RISCV Y-base and
XCheriot. Support for other targets (such as AArch64/MTE and
AArch64/Morello) is left as future work here.
Based on https://github.com/llvm/llvm-project/pull/121957
Co-authored-by: Florian Mayer <fmayer at google.com>
Co-authored-by: Florian Mayer <fmayer at google.com>
[RISCV] Don't overcost wide load in optimized segment load/store (#207146)
With the +optimized-nfX-segment-load-store tuning flag, we cost a
segmented store as a single wide load + some shuffle ops.
However for e.g. a `<vscale x 5 x i64>` Factor=5 segmented load, a wide
`<vscale x 5 x i64>` load gets costed as a full LMUL 8 load.
From what I can see on
https://camel-cdr.github.io/rvv-bench-results/spacemit_x100/index.html
and on my own measurements on the spacemit-x60, uarchs likely don't do a
full LMUL 8 load under the hood and instead dispatch the minimum number
of DLEN sized ops needed for the full segment.
This changes the wide load cost to be divideCeil(vector size, DLEN) ops
so we don't overcost it.
Whilst we're here, this also removes the LT.first legalization
multiplier. We're computing the cost in terms of the unlegalized type so
we shouldn't be scaling it by the legalization cost.
[orc-rt] Add Proxy, a protocol-agnostic controller-call handle (#217792)
Introduce Proxy<RetT(ArgTs...)>, a typed handle for invoking a
controller-side operation from the executor. A Proxy abstracts over how
a call reaches the controller: it holds an opaque callee tag and a
dispatch function (supplied by a per-protocol spec) and forwards calls
through the Session.
This is a cut-down port of llvm/ExecutionEngine/Orc/Proxy.h, with two
deliberate differences:
- The callee is identified by an opaque tag (const void *, typically the
address of a controller-side global) rather than an ExecutorAddr, since
the executor->controller direction dispatches by tag.
- Only the asynchronous (OnComplete) call operator is provided. The
blocking convenience operator is omitted: the executor may be
single-threaded or freestanding and cannot rely on std::promise/future
or on blocking a dispatch thread.
[2 lines not shown]
[SSAF] Fix a stage2 test failure with ASan-instrumented clang - continued
The previous effort in PR#211432 that disables ASan for one static
global is not sufficient. This commit disables ASan for the whole test
plugin.
rdar://182623740
[bazel] Select Windows GNU BLAKE3 assembly for clang-cl (#217695)
## Motivation
This PR is motivated by ongoing work of providing a fully hermetic
clang-cl bazel toolchain built for windows with the MSVC runtime.
The LLVM Bazel overlay does not select a Windows-compatible BLAKE3
assembly source set for an x86_64 Windows target compiled with the
rules_cc `clang-cl` compiler dialect.
The `windows_gnu.S` name can be misleading here. "GNU" describes the
assembly syntax accepted by GNU-style assemblers and Clang's integrated
assembler; it does **not** mean that the implementation uses the MinGW
ABI or runtime. These files implement the Microsoft x64 calling
convention and are intended to produce Windows COFF objects.
A hermetic clang-cl toolchain can therefore assemble the GNU-syntax
Windows sources directly. Selecting the MASM-syntax `windows_msvc.asm`
[25 lines not shown]
[docs] Fix CMAKE_CROSSCOMPILING spelling in HowToCrossCompileLLVM (#217623)
## Summary
The HowToCrossCompileLLVM option list spelled the CMake variable as
`CMAKE_CROSSCOMPIILING` (extra I). The linked CMake docs use
`CMAKE_CROSSCOMPILING`.
Assisted-by: Grok (xAI)
Improve compiler-rt build structure and export compilation info (#190088)
This first improves the structure of the compiler-rt BUILD.bazel, fixing
bugs and exposing more carefully arranged source files.
It also exposes compilation info for builtins and CRT files for use in
compiling these source files.
[mlir][acc] Keep worker-only launches unaligned in ACCCGToGPU (#217382)
Example:
```fortran
!$acc parallel loop worker reduction(+:s) num_workers(16) vector_length(8)
```
In this code, a ThreadY reduction forced blockDim.x to a warp, and
blockDim.y
was divided by the same factor to hold the thread count, so the launch
ran as
(32, 4, 1): 4 workers instead of 16, with the folded-away workers turned
into
ThreadX lanes redoing each other's work.
Fix: skip the alignment when only the workers ask for it and the row
width
divides the subgroup size. Worker reductions combine their partials in
the
[6 lines not shown]
[VPlan] Fix replaceWithFinalIfReductionStore assert with multiple reductions (#217316)
A reductions final value can be simplified away to a constant, which
https://github.com/llvm/llvm-project/pull/201023 handled in
replaceWithFinalIfReductionStore.
However constant live ins can have other users, e.g. a different
reductions start value, in which case the assertion will fail because
we're comparing the backedge value of a different reduction entirely.
Relax the assertion to allow any VPIRValue instead
This an alternative to https://github.com/llvm/llvm-project/pull/217306
that fixes #215071
[CIR] Use CIR type for __dso_handle (#217790)
When CIR's LoweringPrepare pass created the runtime variable for
`__dso_handle` while emitting a guarded dtor region, it was creating the
handle using the builtin `i8` type rather than the CIR equivalent. This
caused the `__cxa_atexit` function to be created with a pointer to that
type, which causes problems for the CIR calling convention lowering
pass.
This change updates the pass to use the CIR type.
[MIPS] Don't mark SLL64_64 as isMoveReg (#214060)
I was running into a Rust miscompilation using pretty standard code (see
bugreport). I had Claude rootcause this to an LLVM bug, where SLL (on 64
bit) is marked as "move", even though it isn't - for full 64-bit values
(with arbitrary upper 32 bits), SLL is not a move as the upper bits get
just sign extended.
The fix itself is tiny and makes sense to me (I know MIPS very well, but
have little LLVM expertise myself). The test for this however is pretty
convoluted as it is quite hard to trigger this bug reliably - it needs
quite some register pressure to actually happen.
On the llvm/test/CodeGen/Mips/madd-msub.ll change: Register indices
changed here as the is the register allocator is now picking a new
independent register instead of reusing an existing one (`sll $4, $4, 0`
changes to `sll $1, $4, 0`). In this particular example that causes
instruction counts to be the same, though in other examples a small
increase is possible (cost of correctness).
[3 lines not shown]
[DebugInfo] Preserve linkage names for profiling (#217536)
Keep DISubprogram linkage names when stripping non-line-table debug
info if the compile unit has debugInfoForProfiling set. This mirrors
-gline-tables-only, which keeps linkage names when
-fdebug-info-for-profiling is enabled.
[clang][SYCL] Derive -triple=/-arch= for clang-sycl-linker in the driver (#217492)
A direct `clang --target=spirv64-unknown-unknown --sycl-link a.bc` does
not tell clang-sycl-linker which device it is finalizing for.
Derive the triple from the target the driver was given, and the
architecture from -march=, and pass them as -triple=/-arch=.
An absent -march= means no specific device was requested. That is
spelled as an absent -arch=, matching how clang-linker-wrapper renders
an offload image that names no device.
A caller may also name these via -Xlinker/-Wl, or (through
clang-linker-wrapper) via -Xoffload-linker. clang-sycl-linker keeps the
last value of each, so derived values are added before an explicitly
given values.
With the driver deriving both values, the SYCL-specific forwarding in
clang-linker-wrapper becomes redundant - it spelled the triple and the
architecture out through -Xlinker after having already passed the very
[2 lines not shown]
[HLSL][LongVec] enable support for all elementwise apis (#216905)
resolves #216103
This change turns on VaryingLongVector for all HLSL intrinsics that map
to an elementwise builtin.
assisted by GPT 5.6-Sol via Copilot
[MLIR][LLVM] Support DWARF v6 source language names in DICompileUnitAttr (#217432)
Adds support to the LLVM dialect `DICompileUnitAttr` for DWARF v6 source
language name and version .
`DICompileUnitAttr`'s `sourceLanugage` field now points to a
`DISourceLanguageNameAttr`, which contains all source language
information, including dialect, name, and version. This is done to map
as closely as possible to `llvm::DISourceLanguageName`.
`DISourceLanguageNameAttr` has parameters for:
- An DW_LANG_* language.
- A DWARF v6 DW_LNAME_* name, which can only be set if the language is
not.
- An optional language-dependent version.
- An optional target-specific language dialect.
Parsers and printers are added so if only a language is passed, it is
parsed and printed in as before this change.
Assistance from codex was used in this PR.