LLVM/project a63dc32clang/lib/CodeGen CGCall.cpp CodeGenModule.h, clang/test/CodeGen call-graph-section-definition-noprototype.c

[clang][CodeGen] Construct function type for callgraph from function definition (#212863)

When -fexperimental-call-graph-section is enabled, for unprototyped
function
definitions (such as C89 parameterless declarations or K&R definitions)
reconstruct their prototype from the parameter declarations in the
definition AST (applying default argument promotions to parameters).

Assisted by: Gemini
DeltaFile
+100-0clang/test/CodeGen/call-graph-section-definition-noprototype.c
+58-3clang/lib/CodeGen/CodeGenModule.cpp
+42-0llvm/test/Linker/callgraph-section-noprototype.ll
+11-0clang/lib/CodeGen/CodeGenModule.h
+1-3clang/lib/CodeGen/CGCall.cpp
+212-65 files

LLVM/project ec4d25allvm/lib/Target/AArch64 AArch64ISelLowering.cpp, llvm/test/CodeGen/AArch64 tail-call-stack-args.ll sme-za-tailcall-fpdiff-align.ll

[llvm][AArch64] Fix FPDiff founding direction in non-sibcall tail calls (#223545)

This fixes another subtle bug in frame accounting (see: #217156 /
#220406), for tail calls that have a non-multiple of 16 bytes worth of
stack arg area, and need that stack arg re-use to be increased to cover
the alignment requirement. This is best illustrated with callers
containing 8 formal arguments covering the first 8 GPRs (x0-x7),
followed by 9 bytes of argument passed on the stack.

In a callee-pops tail call (e.g. tailcc/swifttailcc), the set of
reusable stack arg area bytes has already been sufficiently aligned by
LowerFormalArguments, so growing NumBytes up to StackAlign is enough to
consume that excess. Otherwise (e.g. a plain C-convention call, forced
off the sibcall path, as in the aarch64_inout_za tests), we can't rely
on either having been pre-aligned, so we round NumBytes up to the same
residue mod StackAlign as NumReusableBytes, which cancels the residue
out of their difference (FPDiff), thus keeping the stack aligned going
into the callee.


    [9 lines not shown]
DeltaFile
+108-0llvm/test/CodeGen/AArch64/swifttail-fpdiff-align.ll
+21-16llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
+35-0llvm/test/CodeGen/AArch64/sme-za-tailcall-fpdiff-align.ll
+21-0llvm/test/CodeGen/AArch64/tail-call-stack-args.ll
+185-164 files

LLVM/project eab6573clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/zvzip/policy/non-overloaded vunzipe.c, llvm/lib/Target/Xtensa XtensaS3DSPInstrInfo.td

Merge upstream/main into cir-callconv-vaarg-x86-64

FunctionInfo.h conflicted.  Main added the CanBeFlattened bit exactly where
this branch added NeededIntRegs and NeededSseRegs, and both extended the same
ArgInfo constructor.  All three fields are kept, the bools grouped ahead of
the two 3-bit fields, with the initializer in declaration order.

Assisted-by: Cursor / claude-opus-5
DeltaFile
+4,377-4,141llvm/test/CodeGen/AMDGPU/amdgcn.bitcast.1024bit.ll
+5,753-0llvm/lib/Target/Xtensa/XtensaS3DSPInstrInfo.td
+2,597-2,593llvm/test/CodeGen/AMDGPU/bf16.ll
+2,633-2,496llvm/test/CodeGen/AMDGPU/amdgcn.bitcast.512bit.ll
+1,272-1,259llvm/test/CodeGen/AMDGPU/amdgcn.bitcast.256bit.ll
+145-1,729clang/test/CodeGen/RISCV/rvv-intrinsics-autogenerated/zvzip/policy/non-overloaded/vunzipe.c
+16,777-12,2181,214 files not shown
+70,824-46,5791,220 files

LLVM/project 8fda6e3clang/test/CodeGen PR44896.ll

clang: Require x86 to be built for PR44896.ll test
DeltaFile
+1-0clang/test/CodeGen/PR44896.ll
+1-01 files

LLVM/project 79cfd3dflang/include/flang/Support Fortran.h, flang/lib/Semantics expression.cpp check-call.cpp

[flang][cuda] Limit mem:managed generic matching to allocatable and pointer (#223801)

managed memory mode only puts allocatable and pointer allocations in
managed memory. Static and automatic host objects stay host-resident, so
they must not match a device/managed/unified dummy during generic
resolution.

Keep the -gpu=mem:unified relaxation for all host variables, which are
device-accessible in that mode.

This stops host calls such as sum(host_array(:)) from resolving to a
CUDA Fortran device-dummy specific.
DeltaFile
+69-0flang/test/Semantics/CUDA/cuf-matching-managed-static.cuf
+13-5flang/lib/Support/Fortran.cpp
+11-1flang/lib/Semantics/check-call.cpp
+9-2flang/lib/Semantics/expression.cpp
+1-1flang/include/flang/Support/Fortran.h
+103-95 files

LLVM/project f2e5ab1llvm/test/Transforms/LoopVectorize skeleton-branches-unknown-prof.ll scev-check-unknown-prof.ll

[LV] Add tests for branch weights of branches and selects (NFC). (#224061)

Add for missing branch weights on branches and selects created by LV:
 * Skeleton branches
 * early exit branches
 * various selects.
DeltaFile
+405-0llvm/test/Transforms/LoopVectorize/select-branch-weights.ll
+311-0llvm/test/Transforms/LoopVectorize/early-exit-branch-weights.ll
+211-0llvm/test/Transforms/LoopVectorize/select-unknown-prof.ll
+196-0llvm/test/Transforms/LoopVectorize/replicate-region-guard-unknown-prof.ll
+160-0llvm/test/Transforms/LoopVectorize/scev-check-unknown-prof.ll
+129-0llvm/test/Transforms/LoopVectorize/skeleton-branches-unknown-prof.ll
+1,412-06 files

LLVM/project c9c1ed7lldb/cmake/modules AddLLDB.cmake LLDBConfig.cmake, lldb/source/API CMakeLists.txt

[lldb] Add an option to build liblldb statically (#223210)

This builds on the Emscripten host and platform work from the previous
patches.

`liblldb` is currently always created as a shared library. That makes
sense for the normal LLDB installation, but it is restrictive for
embedders where dynamic libraries are unavailable, expensive to load or
simply not the preferred deployment model.

My immediate use case is bringing LLDB into
[WasmBolt](https://github.com/anutosh491/WasmBolt) (try
[here](https://anutosh21.github.io/WasmBolt/)). Loading the complete
`liblldb` WebAssembly side module dynamically has significant startup
overhead. A static build lets the browser application link the required
LLDB components and plugins into its main module during CI, after which
startup is much faster and the linker can remove unreachable code.

The use case is not specific to Emscripten, so this patch adds the

    [22 lines not shown]
DeltaFile
+12-3lldb/source/API/CMakeLists.txt
+12-0lldb/cmake/modules/LLDBConfig.cmake
+2-1lldb/cmake/modules/AddLLDB.cmake
+26-43 files

LLVM/project 64b49cbllvm/lib/Target/Xtensa XtensaS3DSPInstrInfo.td, llvm/test/CodeGen/AMDGPU amdgcn.bitcast.512bit.ll bf16.ll

Merge branch 'main' into users/adams381/cir-callconv-argmem-memory-effects
DeltaFile
+4,377-4,141llvm/test/CodeGen/AMDGPU/amdgcn.bitcast.1024bit.ll
+5,753-0llvm/lib/Target/Xtensa/XtensaS3DSPInstrInfo.td
+2,597-2,593llvm/test/CodeGen/AMDGPU/bf16.ll
+2,633-2,496llvm/test/CodeGen/AMDGPU/amdgcn.bitcast.512bit.ll
+4,864-0llvm/test/CodeGen/RISCV/smulh.ll
+4,319-0llvm/test/CodeGen/RISCV/umulh.ll
+24,543-9,2301,739 files not shown
+106,336-55,2961,745 files

LLVM/project 1cc3e31mlir/lib/Conversion/AMDGPUToROCDL AMDGPUToROCDL.cpp, mlir/lib/Conversion/GPUToROCDL LowerGpuOpsToROCDLOps.cpp

[mlir] Migrate AMDGPU/ROCDL to targets, not chipset versions

**migration tl;dr:** Replace usages of `amdgpu::Chipset` with `ROCDL::TargetInfo`, ideally move from `chipset=` to `arch=`. If you don't use upstream pipelines, call 'TargetInfo::migrateArchFeaturesToModuleFlags` at the appropriate location.

Further note: if you've got a build pipeline that's getting a `gfxXXX` name from something like `rocm_agent_enumerator`, using a full triple name like the ones you get from `rocminfo` is preferred.

`amdgpu::Chipset` was an awkward hack that was hard to keep up to date
with changes in the compiler/new architectures, and didn't properly
support generic targets (and has been strongly disfavored by the
compiler team).

This PR replaces `amdgpu::Chipset` with `ROCDL::TargetInfo`, a
structure that uses LLVM's TargetParser and the underlying LLVM
features tables to get the real nature of the target being compiled
for.

This also helps MLIR move to
new-style (`-mtriple=amdgpuX.YZ-amd-amdhsa`) over "old
style" (`-mtriple=amdgcn-amd-amdhsa -mcpu=gfxXYZ`) triples.

    [36 lines not shown]
DeltaFile
+316-323mlir/lib/Conversion/AMDGPUToROCDL/AMDGPUToROCDL.cpp
+105-0mlir/test/Dialect/LLVMIR/rocdl-attach-target-arch.mlir
+87-4mlir/lib/Dialect/GPU/Transforms/ROCDLAttachTarget.cpp
+46-40mlir/lib/Dialect/AMDGPU/Transforms/EmulateAtomics.cpp
+49-24mlir/test/Dialect/AMDGPU/amdgpu-emulate-atomics.mlir
+30-30mlir/lib/Conversion/GPUToROCDL/LowerGpuOpsToROCDLOps.cpp
+633-421103 files not shown
+1,181-718109 files

LLVM/project 90ab3a7mlir/include/mlir/Dialect/LLVMIR ROCDLTargetInfo.h, mlir/lib/Dialect/LLVMIR CMakeLists.txt

[mlir][ROCDL] Add TargetInfo to replace Chipset, allow features queries

Add a now ROCDL::TargetInfo struct that parses AMDGPU triples and
target names using the same logic that Clang and LLVM
use (TargetParser) and maintains the set of features available on a
given GPU.

This is an improvement over the old `amdgpu::Chipset` struct since
that was just a version number and often became stale compared to the
knowledge exposed by LLVM, such as gfx1170 having OCP FP8 support even
though other gfx11 chips don't have it.

This struct also allows for moving to new-style
triples (amdgpu9.42-amd-amdhsa vs amdgcn-amd-amdhsa--gfx942, for
example), which is an ongoing migration in other parts of the compiler
that this PR lets us follow.

It also enables compiling for generic targets, like `gfx11-generic`,
which can be run on all chips in a generation.

    [15 lines not shown]
DeltaFile
+392-0mlir/unittests/Dialect/LLVMIR/ROCDLTargetInfoTest.cpp
+242-0mlir/lib/Dialect/LLVMIR/IR/ROCDLTargetInfo.cpp
+193-0mlir/include/mlir/Dialect/LLVMIR/ROCDLTargetInfo.h
+2-0mlir/unittests/Dialect/LLVMIR/CMakeLists.txt
+2-0mlir/lib/Dialect/LLVMIR/CMakeLists.txt
+831-05 files

LLVM/project 4beedd8llvm/lib/Target/AMDGPU AMDGPUPromoteAlloca.cpp, llvm/test/CodeGen/AMDGPU eliminate-frame-index-select.ll promote-alloca-homogeneous-struct.ll

Reland "[AMDGPU] PromoteAlloca: flatten homogeneous structs to vectors" (#221058)

This relands #217055

The original commit revealed a latent issue in eliminateFrameIndex in
SIRegisterInfo where SCC can be clobbered before reading it on
gfx900/gfx90a. This change itself has no known issues.
DeltaFile
+152-0llvm/test/CodeGen/AMDGPU/promote-alloca-homogeneous-struct.ll
+23-6llvm/lib/Target/AMDGPU/AMDGPUPromoteAlloca.cpp
+6-1llvm/test/CodeGen/AMDGPU/eliminate-frame-index-select.ll
+181-73 files

LLVM/project 4c88d7cllvm/lib/Target/AMDGPU SIRegisterInfo.cpp, llvm/test/CodeGen/AMDGPU sgpr-spill-to-vmem-scc-clobber-reserved-exec-copy.mir

[AMDGPU] Don't spill an SGPR while SCC is live in frame index lowering

When SCC is live into a scalar frame index user, the scaling path avoids
SALU ops that write SCC by computing the address in a VGPR and reading it
back with V_READFIRSTLANE_B32. If the destination of that readfirstlane is
scavenged with spilling allowed, an AMDGPU SGPR spill writes inactive
lanes, so it flips EXEC with S_NOT_B64 and clobbers SCC. Instead, scavenge
that register with AllowSpill=false.
DeltaFile
+207-0llvm/test/CodeGen/AMDGPU/sgpr-spill-to-vmem-scc-clobber-reserved-exec-copy.mir
+30-11llvm/lib/Target/AMDGPU/SIRegisterInfo.cpp
+237-112 files

LLVM/project 1db8b8fllvm/lib/Target/AMDGPU SIRegisterInfo.cpp, llvm/test/CodeGen/AMDGPU sgpr-spill-to-vmem-scc-clobber-reserved-exec-copy.mir

[AMDGPU] Only scale the frame register in place for the last frame index

When nothing can be scavenged, eliminateFrameIndex falls back to scaling
FrameReg in place and restoring it after MI. With two frame indices on
one instruction that fallback fires while lowering the first one, and
FrameReg is left scaled for everything that follows: the second frame
index is then scaled a second time from the already-scaled value, and any
emergency spill emitted in between uses it as its scratch offset.
DeltaFile
+78-0llvm/test/CodeGen/AMDGPU/sgpr-spill-to-vmem-scc-clobber-reserved-exec-copy.mir
+9-0llvm/lib/Target/AMDGPU/SIRegisterInfo.cpp
+87-02 files

LLVM/project bf02a67llvm/lib/Target/AMDGPU SIRegisterInfo.cpp, llvm/test/CodeGen/AMDGPU eliminate-frame-index-scalar-scc-clobber.mir

[AMDGPU] Prevent SCC clobber in frame index lowering in scaling path

eliminateFrameIndex has two lowering strategies, but only one has the
proper handling for checking SCC-liveness to prevent clobbering. Unify
them with a helper function to ensure both paths handle the same
DeltaFile
+343-4llvm/test/CodeGen/AMDGPU/eliminate-frame-index-scalar-scc-clobber.mir
+9-5llvm/lib/Target/AMDGPU/SIRegisterInfo.cpp
+352-92 files

LLVM/project 543f4c9flang/lib/Semantics mod-file.cpp resolve-directives.cpp, flang/test/Lower/OpenACC acc-routine-bind-cuda-modfile.cuf

[flang][openacc][cuda] Recover acc routine bind info in CUDA Fortran module reads (#223595)

CUDA Fortran device code can call a procedure whose device-side symbol
is given by `acc routine bind(...)` in the module that declares it.
The using translation unit is often compiled with CUDA Fortran enabled
and without an OpenACC target, so the `$acc` sentinel was never
recognized when re-parsing the module file and the bind clause was
dropped.
Enable OpenACC while reading module files under CUDA Fortran as well,
and resolve the recovered directives onto the imported symbols. User
`$acc` in the main source remains ignored without `-fopenacc`; only
directives that already survived into the `.mod` are honored.
A bind(C) host name and an acc bind device name on the same procedure
is the dual-name rule in OpenACC §2.15.1.
DeltaFile
+44-0flang/test/Lower/OpenACC/acc-routine-bind-cuda-modfile.cuf
+7-1flang/lib/Semantics/resolve-directives.cpp
+6-1flang/lib/Semantics/mod-file.cpp
+57-23 files

LLVM/project 2684a78llvm/include/llvm/Target Target.td, llvm/lib/Target/PowerPC PPCRegisterInfo.cpp

CodeGen: Remove PointerLikeRegClass

Remove PointerLikeRegClass and the related getPointerRegClass
TargetRegisterInfo hook. This is obsoleted by RegClassByHwMode.
Previously targets would have to map ptr_rc to an assumed pointer
register class by implementing this method, but this is now auto-resolvable
per instruction using RegClassByHwMode.

Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>

Remove getRegClassByHwMode
DeltaFile
+9-19llvm/include/llvm/Target/Target.td
+14-8llvm/utils/TableGen/InstrInfoEmitter.cpp
+0-17llvm/lib/Target/PowerPC/PPCRegisterInfo.cpp
+13-0llvm/utils/TableGen/Common/CodeGenTarget.cpp
+0-12llvm/lib/Target/X86/X86RegisterInfo.cpp
+5-4llvm/utils/TableGen/Common/CodeGenTarget.h
+41-6031 files not shown
+46-19437 files

LLVM/project 52f3151llvm/include/llvm/CodeGen TargetInstrInfo.h, llvm/lib/Target/AArch64 AArch64ISelDAGToDAG.cpp

CodeGen: Add getInlineAsmMemoryOperandRegClass

Replace the use of getPointerRegClass to determine the register
class from an asm memory constraint, working to delete it. When
there are multiple pointer types there can't be just a single
answer.

Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
DeltaFile
+11-0llvm/lib/Target/X86/X86InstrInfo.cpp
+8-0llvm/lib/Target/WebAssembly/WebAssemblyInstrInfo.cpp
+4-3llvm/lib/Target/AArch64/AArch64ISelDAGToDAG.cpp
+7-0llvm/lib/Target/AMDGPU/SIInstrInfo.h
+7-0llvm/include/llvm/CodeGen/TargetInstrInfo.h
+6-0llvm/lib/Target/PowerPC/PPCInstrInfo.cpp
+43-321 files not shown
+128-727 files

LLVM/project ef7c0b5llvm/lib/CodeGen/GlobalISel IRTranslator.cpp, llvm/lib/Target/PowerPC PPCRegisterInfo.cpp

CodeGen: Replace some getPointerRegClass() uses with operand reg classes (#223930)

Try to take the register class from the contexual instruction being
emitted instead. This is a step towards fully replacing PointerLikeRegClass with
RegClassByHwMode.

Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
DeltaFile
+3-2llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp
+1-3llvm/lib/Target/PowerPC/PPCRegisterInfo.cpp
+2-2llvm/lib/Target/WebAssembly/WebAssemblyRegisterInfo.cpp
+2-2llvm/lib/Target/WebAssembly/WebAssemblyFrameLowering.cpp
+8-94 files

LLVM/project a00dc85clang/test/CodeGen/RISCV rvp-intrinsics.c, flang/test/Lower split-sum-expression-tree-lowering.f90

Merge branch 'main' into users/adams381/cir-callconv-union-tail-padding
DeltaFile
+214-182flang/test/Lower/split-sum-expression-tree-lowering.f90
+289-0llvm/test/Analysis/CostModel/X86/arith-mulh.ll
+150-105llvm/lib/Transforms/Vectorize/SandboxVectorizer/Passes/LoadStoreVec.cpp
+189-29llvm/unittests/ABI/AArch64TargetInfoTest.cpp
+182-0clang/test/CodeGen/RISCV/rvp-intrinsics.c
+38-80llvm/lib/Target/AMDGPU/AMDGPUCoExecInfo.h
+1,062-396148 files not shown
+2,957-911154 files

LLVM/project d8a3beallvm/include/llvm/IR GlobalValue.h, llvm/include/llvm/Transforms/Utils SplitModuleCommon.h

[NFC][IR][GlobalValue] Move externalize helpers to GlobalValue (#223654)

This PR is a revised refactoring of #221181.
To improve generality, it makes the splitting helpers
externalizeGlobal() and nameUnnamedGlobalValue() generic members of
GlobalValue and removes SplitModuleCommon:

- GlobalValue::externalize() promotes a local-linkage global to external
+ hidden and names it if unnamed.
- GlobalValue::nameUnnamed() names unnamed globals __llvm_unnamed.

Co-authored-by: maojiaping <maojiaping1.huawei.com>
DeltaFile
+0-33llvm/lib/Transforms/Utils/SplitModuleCommon.cpp
+0-33llvm/include/llvm/Transforms/Utils/SplitModuleCommon.h
+17-0llvm/include/llvm/IR/GlobalValue.h
+8-8llvm/test/tools/llvm-split/unnamed.ll
+5-6llvm/lib/Transforms/Utils/SplitModule.cpp
+3-4llvm/lib/Target/AMDGPU/AMDGPUSplitModule.cpp
+33-841 files not shown
+33-857 files

LLVM/project 3bc966aoffload/plugins-nextgen/common/include PluginInterface.h, offload/plugins-nextgen/level_zero/include L0Device.h

[Offload] Minor changes to address build issues (#224047)

This patch includes a few changes to fix customized build process of
offload components with relatively old build compilers. Current LLVM
build does not need this change since it uses just-built clang to build
offload components, but it does not hurt to make the code buildable with
other compilers.

Assisted by Claude Code.
DeltaFile
+5-5offload/plugins-nextgen/level_zero/include/L0Device.h
+5-1offload/plugins-nextgen/common/include/PluginInterface.h
+10-62 files

LLVM/project 9cc2e03llvm/lib/CodeGen RDFGraph.cpp MachineBasicBlock.cpp, llvm/lib/CodeGen/GlobalISel IRTranslator.cpp

CodeGen: Read the exception model from the module flag in EH lowering (#223970)

Resolve the exception model as the exception-model module flag if
present, otherwise the TargetOptions default.

Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
DeltaFile
+13-8llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp
+8-4llvm/lib/Target/XCore/XCoreFrameLowering.cpp
+8-4llvm/lib/CodeGen/MachineLICM.cpp
+7-4llvm/lib/CodeGen/RDFGraph.cpp
+7-4llvm/lib/CodeGen/MachineBasicBlock.cpp
+6-3llvm/test/CodeGen/WebAssembly/lower-em-exceptions.ll
+49-2712 files not shown
+89-4318 files

LLVM/project 31f89f8llvm/lib/Transforms/Vectorize SLPVectorizer.cpp, llvm/test/Transforms/SLPVectorizer/AArch64 splat-gather-subtree-inst-count.ll

[𝘀𝗽𝗿] initial version

Created using spr 1.3.7
DeltaFile
+110-21llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
+10-11llvm/test/Transforms/SLPVectorizer/AArch64/splat-gather-subtree-inst-count.ll
+120-322 files

LLVM/project dcc6653flang/lib/Lower/OpenMP Utils.cpp ClauseProcessor.cpp, flang/test/Lower/OpenMP iterator-ranges.f90 declare-mapper-iterator.f90

[flang][OpenMP] Lower iterator modifiers in map and motion clauses

Add iterator lowering for `target data`, `target enter/exit data`,
`target update`, and map clauses inside `declare mapper`.

For example:

```fortran
!$omp target update to(iterator(i=1:n): a(i), b)
```

Conceptually, this becomes:

```text
entries = omp.iterator(i = 1 through n) {
  yield map_info(base = a, bounds = element i)
}
target_update(iterated_maps = entries, ordinary_maps = [b])
```

    [37 lines not shown]
DeltaFile
+951-0flang/test/Lower/OpenMP/motion-iterator.f90
+293-0flang/test/Lower/OpenMP/declare-mapper-iterator.f90
+186-34flang/lib/Lower/OpenMP/ClauseProcessor.cpp
+187-0flang/lib/Lower/OpenMP/Utils.cpp
+160-0flang/test/Lower/OpenMP/iterator-ranges.f90
+124-17mlir/test/Target/LLVMIR/openmp-iterator.mlir
+1,901-5126 files not shown
+2,549-21632 files

LLVM/project 01edf18libcxx/utils/ci buildkite-pipeline.yml

[libc++][ci] Retarget the ARM BuildKite runners (#224107)

I enabled agent clusters in BuildKite since unclustered agents are not
supported anymore. As part of that, I created a new libcxx-builders-arm
queue to replace the existing queue. This patch switches the pipeline
definition so that new jobs start targeting the new queue with clustered
agents.
DeltaFile
+8-8libcxx/utils/ci/buildkite-pipeline.yml
+8-81 files

LLVM/project 203c5aellvm/lib/ExecutionEngine/Orc/Shared CMakeLists.txt

[ORC] Link LLVMOrcShared against TargetParser

Mangler::fromTriple() calls Triple::computeDataLayout(), which lives in
LLVMTargetParser, but LLVMOrcShared only lists Support as a link
component.

This goes unnoticed in a static build: the component is an archive, so
the reference is not resolved until the final executable link, where
LLVMTargetParser is present anyway. With BUILD_SHARED_LIBS=ON each
component becomes a shared library linked with -Wl,-z,defs, and linking
LLVMOrcShared itself fails:

  ld.lld: error: undefined symbol:
    llvm::Triple::computeDataLayout[abi:cxx11](llvm::StringRef) const
  >>> referenced by Mangler.cpp:50
DeltaFile
+1-0llvm/lib/ExecutionEngine/Orc/Shared/CMakeLists.txt
+1-01 files

LLVM/project ea5b2bellvm/lib/Transforms/Utils RelLookupTableConverter.cpp, llvm/test/Transforms/RelLookupTableConverter/X86 relative_lookup_table.ll

[RelLookupTableConverter] Allow multiple uses of loaded value (#223853)

RelLookupTableConverter previously required `!Load ||
!Load->hasOneUse()`, which prevented converting lookup tables if the
loaded pointer was used more than once in the function.

This restriction is unnecessary since the loaded value itself can be
used many times. The check was likely an over-zealous carryover from
`GV->hasOneUse()` and `GEP->hasOneUse()`.

Remove the check and add a test verifying that lookup tables with
multiple uses of the loaded pointer are converted.
DeltaFile
+22-0llvm/test/Transforms/RelLookupTableConverter/X86/relative_lookup_table.ll
+1-1llvm/lib/Transforms/Utils/RelLookupTableConverter.cpp
+23-12 files

LLVM/project a26f60fflang/lib/Lower/OpenMP Utils.cpp ClauseProcessor.cpp, flang/test/Lower/OpenMP iterator-ranges.f90 declare-mapper-iterator.f90

[flang][OpenMP] Lower iterator modifiers in map and motion clauses

Add iterator lowering for `target data`, `target enter/exit data`,
`target update`, and map clauses inside `declare mapper`.

For example:

```fortran
!$omp target update to(iterator(i=1:n): a(i), b)
```

Conceptually, this becomes:

```text
entries = omp.iterator(i = 1 through n) {
  yield map_info(base = a, bounds = element i)
}
target_update(iterated_maps = entries, ordinary_maps = [b])
```

    [20 lines not shown]
DeltaFile
+951-0flang/test/Lower/OpenMP/motion-iterator.f90
+293-0flang/test/Lower/OpenMP/declare-mapper-iterator.f90
+186-34flang/lib/Lower/OpenMP/ClauseProcessor.cpp
+187-0flang/lib/Lower/OpenMP/Utils.cpp
+160-0flang/test/Lower/OpenMP/iterator-ranges.f90
+124-17mlir/test/Target/LLVMIR/openmp-iterator.mlir
+1,901-5126 files not shown
+2,549-21632 files

LLVM/project 22b6009llvm/lib/CAS MappedFileRegionArena.cpp

[𝘀𝗽𝗿] initial version

Created using spr 1.3.7
DeltaFile
+1-1llvm/lib/CAS/MappedFileRegionArena.cpp
+1-11 files

LLVM/project 49a10dellvm/docs AMDGPUUsage.rst

[AMDGPU][Doc] Add documentation about ABI occupancy

This PR introduces ABI occupancy in documentation. The actual code
implementation will be in follow-up PRs.
DeltaFile
+47-2llvm/docs/AMDGPUUsage.rst
+47-21 files