LLVM/project a8c7d3e — flang/lib/Evaluate fold.cpp formatting.cpp, flang/lib/Semantics assignment.cpp

[flang] Fix NOTIFY= placement checking and folding (#231660)

F2023 C933 permits NOTIFY= only in the image selector of an intrinsic
assignment's target variable. Before this patch, semantic analysis
accepted it in other contexts.

Assignment checking reuses the analyzed assignment's classification as
intrinsic or defined. For intrinsic assignment, an existing parse-tree
helper identifies the target variable's own image selector. The new
check permits a NOTIFY= specifier only if its parse-tree node belongs to
that selector's specifier list. It rejects NOTIFY= on separate
designators nested within the target variable.

If an operand error prevents assignment analysis, the checker avoids an
extra placement diagnostic on the target's own selector. Existing
duplicate-specifier diagnostics remain unchanged.

Before this patch, FoldOperation(CoarrayRef) dropped NOTIFY= from the
rebuilt reference. The change retains and folds the notification

    [8 lines not shown]
DeltaFile
+163-0flang/test/Semantics/notify-assignment-errors.f90
+101-0flang/test/Semantics/notify-assignment-valid.f90
+69-0flang/unittests/Evaluate/expression.cpp
+35-3flang/lib/Semantics/assignment.cpp
+4-0flang/lib/Evaluate/formatting.cpp
+3-0flang/lib/Evaluate/fold.cpp
+375-32 files not shown
+378-38 files

LLVM/project cebd70d — flang/include/flang/Optimizer/Passes CommandLineOpts.h, flang/lib/Optimizer/Passes Pipelines.cpp CommandLineOpts.cpp

[flang][NFC] Expose force-no-alias option via CommandLineOpts (#232568)

Move the force-no-alias cl::opt from a file-local static in
Pipelines.cpp
to CommandLineOpts.cpp and declare it extern in CommandLineOpts.h, so
other pipelines built on top of flang can honor the same setting without
re-registering the option.
DeltaFile
+0-4flang/lib/Optimizer/Passes/Pipelines.cpp
+4-0flang/lib/Optimizer/Passes/CommandLineOpts.cpp
+1-0flang/include/flang/Optimizer/Passes/CommandLineOpts.h
+5-43 files

LLVM/project 2c0d9a6 — mlir/include/mlir/IR Diagnostics.h, mlir/lib/IR Diagnostics.cpp

[mlir][Diagnostics] Set parallel diagnostic order ids without a lock (#232520)

failableParallelForEach tells its ParallelDiagnosticHandler which
element each thread is processing before every element and clears it
after, so diagnostics come out in element order.

The order id now lives in a thread-local slot naming its handler by a
monotonic id (no raw pointers, so a handler destroyed with a stale slot
naming it is harmless). A thread handles one element at a time per
handler, so the slot covers every thread whose loop is not nested in
another loop on the same thread.

200K single-op func.func through per-function cse, 96 threads: sys time
22.9s to 3.8s, wall 3.4s to 3.2s. Unittest pins the nested fallback and
outer-id preservation.
DeltaFile
+141-0mlir/unittests/IR/Diagnostic.cpp
+69-8mlir/lib/IR/Diagnostics.cpp
+6-1mlir/include/mlir/IR/Diagnostics.h
+216-93 files

LLVM/project f93450b — mlir/lib/Transforms/Utils GreedyPatternRewriteDriver.cpp

[mlir] Check greedy rewrite fingerprints at entry points
DeltaFile
+28-0mlir/lib/Transforms/Utils/GreedyPatternRewriteDriver.cpp
+28-01 files

LLVM/project d7ae865 — bolt/lib/Core BinaryFunction.cpp, bolt/test/X86 jump-past-section-end.s

[BOLT] Expand builtin_unreachable recognition heuristics (#231258)

A jump to the address right past the end of a function (the result of
__builtin_unreachable()) was replaced with a nop only when the target
was within the function's padding (MaxSize). However, there is a corner
case for the very last function in a section: MaxSize equals Size, so
BOLT would see __builtin_unreachable() instead as as an interprocedural
reference to an address outside of any section, tripping the "cannot get
section for referenced address" assertion in
processInterproceduralReferences(). Fix this.
DeltaFile
+37-0bolt/test/X86/jump-past-section-end.s
+5-3bolt/lib/Core/BinaryFunction.cpp
+42-32 files

LLVM/project b3353c0 — llvm/test/CodeGen/X86 asm-constraints-rm.ll inline-asm-direct-mem-output-error.ll

[X86] Address review: test a tied input's untied read under -regalloc=fast

Add the case from the #229630 review, one value passed to an untied "r"
input and to the "0" input tied to an "rm" output, to show that the fast
register allocator no longer folds the output when everything fits.

Drop the -O0 RUN line from inline-asm-direct-mem-output-error.ll: it only
showed that "=rm" still picks memory at -O0, which asm-constraints-rm.ll
already tests, and there make the -O0 line name the instruction selector
and say that it tests the optimization level.

Assisted-by: Claude Opus 5.5
DeltaFile
+87-0llvm/test/CodeGen/X86/asm-constraints-rm-pressure.ll
+2-7llvm/test/CodeGen/X86/inline-asm-direct-mem-output-error.ll
+5-1llvm/test/CodeGen/X86/asm-constraints-rm.ll
+94-83 files

LLVM/project cc38bef — llvm/lib/CodeGen/SelectionDAG TargetLowering.cpp, llvm/test/CodeGen/X86 asm-constraints-rm-callbr-fold.ll asm-constraints-rm-isel.ll

[TargetLowering][X86] Prefer 'r' over 'm' for foldable "rm" inline asm operands

An "rm" (register-or-memory) inline asm operand has always resolved to
'm', because getConstraintPreferences() picks the most general
constraint present, and 'm' is more general than 'r'. That's safe, since
memory can't run out, but it forces a value that could stay in a
register through a stack slot even when there's no register pressure
(https://github.com/llvm/llvm-project/issues/20571).

Prefer 'r' instead where the register allocator can fold the register
back to a stack slot when it runs out of registers, and mark the
register operand foldable (InlineAsm::Flag::setRegMayBeFolded()) so it
does. Both allocators can: the greedy allocator folds an operand when it
spills its value, and the fast allocator folds operands up front when
the asm's register operands wouldn't fit.

ParseConstraints() sets AsmOperandInfo::MayFoldRegister for an operand
whose constraint codes include 'r' and 'm' and are otherwise only
immediate codes, above -O0, on a target that opts in through the new

    [26 lines not shown]
DeltaFile
+788-0llvm/test/CodeGen/X86/asm-constraints-rm-pressure.ll
+767-0llvm/test/CodeGen/X86/asm-constraints-torture.ll
+227-0llvm/test/CodeGen/X86/inline-asm-callbase.ll
+157-0llvm/test/CodeGen/X86/asm-constraints-rm-isel.ll
+73-2llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp
+74-0llvm/test/CodeGen/X86/asm-constraints-rm-callbr-fold.ll
+2,086-29 files not shown
+2,175-1715 files

LLVM/project 36c85ed — llvm/lib/CodeGen RegAllocFast.cpp

[RegAllocFast] Reformat

Assisted-by: Claude Opus 5.5
DeltaFile
+2-2llvm/lib/CodeGen/RegAllocFast.cpp
+2-21 files

LLVM/project d9f1a22 — llvm/lib/Transforms/InstCombine InstCombineSelect.cpp, llvm/test/CodeGen/AMDGPU simplify-libcalls.ll amdgpu-simplify-libcall-pow.ll

[InstCombine][AMDGPU] Fold select of intrinsics differing in one operand (#227737)

When both arms of a select are calls with one use to the same trivially
vectorizable intrinsic and differ in exactly one operand, sink the
select
into that operand:

$$\mathrm{select}(c,\ f(x, y),\ f(x, z)) \to f(x,\ \mathrm{select}(c, y,
z))$$

This removes one call. FMF are intersected, and the new call takes the
debug location of the select.

The fold is skipped when:
* the differing operand is an immarg,
* either differing operand is a constant, since that may enable a
cheaper
  lowering (e.g. $x^2 \to x \cdot x$),
* the condition is a vector but the differing operand is a scalar, as

    [3 lines not shown]
DeltaFile
+38-51llvm/test/Transforms/InstCombine/intrinsic-select.ll
+18-36llvm/test/CodeGen/AMDGPU/amdgpu-simplify-libcall-rootn.ll
+44-9llvm/lib/Transforms/InstCombine/InstCombineSelect.cpp
+9-11llvm/test/CodeGen/AMDGPU/amdgpu-simplify-libcall-pow.ll
+2-4llvm/test/CodeGen/AMDGPU/simplify-libcalls.ll
+2-3llvm/test/Transforms/InstCombine/select-fcmp-fmul-zero-absorbing-value.ll
+113-1146 files

LLVM/project fe846c9 — mlir/include/mlir/Transforms FoldUtils.h, mlir/lib/Transforms/Utils FoldUtils.cpp GreedyPatternRewriteDriver.cpp

[mlir] Track known constant insertion effects
DeltaFile
+15-4mlir/include/mlir/Transforms/FoldUtils.h
+9-5mlir/lib/Transforms/Utils/GreedyPatternRewriteDriver.cpp
+9-4mlir/lib/Transforms/Utils/FoldUtils.cpp
+33-133 files

LLVM/project 461ea70 — llvm/lib/CodeGen RegAllocFast.cpp, llvm/test/CodeGen/X86 regallocfast-inline-asm-fold-tied-input.mir

[RegAllocFast] Address review: don't recount a tied input's untied reads

When one value is passed to both a tied operand and an untied one, e.g.
"=rm"(r) : "r"(v), "0"(v), with an explicit -regalloc=fast above -O0 (so
TwoAddress doesn't run and the ties reach RegAllocFast), the fold estimate
counted three registers where lowerTiedUse() uses one. Tied uses are
allocated first, so the value moves into the def's register and the untied
read is rewritten to it. tiedUseNeedsOwnReg() still assumed another read of
the value could get it a register first, and the untied read was counted on
its own as well, so the asm's output was folded to the stack needlessly.

Model the tied input itself: while one of its tied defs is in a register,
it needs no register of its own unless tiedUseNeedsOwnReg() says so (only
an early-clobber def now makes another read matter), and its untied reads
share whichever register it has. Once its tied defs are folded, the untied
reads need a register again, so choose what to fold by counting again with
each candidate folded, and fold both halves when neither alone helps.

Assisted-by: Claude Opus 5.5
DeltaFile
+209-0llvm/test/CodeGen/X86/regallocfast-inline-asm-fold-tied-input.mir
+69-19llvm/lib/CodeGen/RegAllocFast.cpp
+278-192 files

LLVM/project ae814af — clang/test/CodeGen/AArch64/sve maxnmv.c, clang/test/CodeGen/AArch64/sve-intrinsics acle_sve_maxnmv.c

[clang][CIR] Add tests for SVE MAXNMV intrinsics (#232198)

adds CIR tests for `svmaxnmv` (plain SVE) intrinsics.

Moves and adapts `sve-intrinsics/acle_sve_maxnmv.c` to `sve/maxnmv.c`

Part of #223963
DeltaFile
+85-0clang/test/CodeGen/AArch64/sve/maxnmv.c
+0-75clang/test/CodeGen/AArch64/sve-intrinsics/acle_sve_maxnmv.c
+85-752 files

LLVM/project 78ed659 — clang/test/CodeGen/AArch64/sve minnmv.c, clang/test/CodeGen/AArch64/sve-intrinsics acle_sve_minnmv.c

[clang][CIR] Add tests for SVE MINNMV intrinsics (#232199)

adds CIR tests for `svminnmv` (plain SVE) intrinsics.

Moves and adapts `sve-intrinsics/acle_sve_minnmv.c` to `sve/minnmv.c`

Part of #223963
DeltaFile
+85-0clang/test/CodeGen/AArch64/sve/minnmv.c
+0-75clang/test/CodeGen/AArch64/sve-intrinsics/acle_sve_minnmv.c
+85-752 files

LLVM/project 8059237 — llvm/docs RISCVUsage.md

[RISCV][Docs] Rename Extensions section in RISCVUsage to 'Ratified Extensions' (#232488)

We have separate sections for Experimental and Vendor so let's name this
what it is.
DeltaFile
+1-1llvm/docs/RISCVUsage.md
+1-11 files

LLVM/project ee70066 — lldb/source/Plugins/Process/Utility RegisterContextLinux_x86_64.cpp RegisterInfoLinux_x86_64.cpp, lldb/unittests/Process/Utility RegisterContextFreeBSDTest.cpp RegisterInfoFreeBSDTest.cpp

[lldb] Rename OS register metadata providers (#231564)

Rename platform/arch-specific RegisterContext* to RegisterInfo* under
Process/Utility as these files contain classes derived from
RegisterInfoInterface not RegisterContext.
DeltaFile
+0-494lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp
+494-0lldb/unittests/Process/Utility/RegisterInfoFreeBSDTest.cpp
+0-233lldb/source/Plugins/Process/Utility/RegisterContextFreeBSD_powerpc.cpp
+233-0lldb/source/Plugins/Process/Utility/RegisterInfoFreeBSD_powerpc.cpp
+0-186lldb/source/Plugins/Process/Utility/RegisterContextLinux_x86_64.cpp
+186-0lldb/source/Plugins/Process/Utility/RegisterInfoLinux_x86_64.cpp
+913-91369 files not shown
+2,868-2,86975 files

LLVM/project b6a4240 — llvm/lib/CodeGen/SelectionDAG TargetLowering.cpp, llvm/test/CodeGen/X86 asm-constraints-rm-callbr-fold.ll asm-constraints-rm-isel.ll

[TargetLowering][X86] Prefer 'r' over 'm' for foldable "rm" inline asm operands

An "rm" (register-or-memory) inline asm operand has always resolved to
'm', because getConstraintPreferences() picks the most general
constraint present, and 'm' is more general than 'r'. That's safe, since
memory can't run out, but it forces a value that could stay in a
register through a stack slot even when there's no register pressure
(https://github.com/llvm/llvm-project/issues/20571).

Prefer 'r' instead where the register allocator can fold the register
back to a stack slot when it runs out of registers, and mark the
register operand foldable (InlineAsm::Flag::setRegMayBeFolded()) so it
does. Both allocators can: the greedy allocator folds an operand when it
spills its value, and the fast allocator folds operands up front when
the asm's register operands wouldn't fit.

ParseConstraints() sets AsmOperandInfo::MayFoldRegister for an operand
whose constraint codes include 'r' and 'm' and are otherwise only
immediate codes, above -O0, on a target that opts in through the new

    [26 lines not shown]
DeltaFile
+788-0llvm/test/CodeGen/X86/asm-constraints-rm-pressure.ll
+767-0llvm/test/CodeGen/X86/asm-constraints-torture.ll
+227-0llvm/test/CodeGen/X86/inline-asm-callbase.ll
+157-0llvm/test/CodeGen/X86/asm-constraints-rm-isel.ll
+73-2llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp
+74-0llvm/test/CodeGen/X86/asm-constraints-rm-callbr-fold.ll
+2,086-29 files not shown
+2,175-1715 files

LLVM/project f254d47 — llvm/lib/CodeGen RegAllocFast.cpp, llvm/test/CodeGen/X86 regallocfast-inline-asm-fold.mir regallocfast-inline-asm-fold-pressure.mir

[RegAllocFast] Fold foldable inline asm operands under register pressure

An inline asm register operand marked foldable (from an "rm" constraint)
may be replaced with a stack slot when the register allocator runs out
of registers. The greedy allocator does that when it spills the value.
The fast allocator can't: it assigns the operands of an instruction one
at a time, and folding replaces the instruction. So it reported
"inline assembly requires more registers than available" instead.

Before allocating a block, estimate from each inline asm's own operands
whether they fit in registers, and fold as many foldable registers as
needed to make them fit, so the common case without pressure still gets
a register. Values that only live across the asm don't count, since the
allocator spills them when it needs their registers. The estimate
follows allocateInstruction():

- First all defs get distinct registers, avoiding physreg defs; then all
  uses, along with the defs still occupied while the uses are read
  (early-clobber and tied defs, see isLiveThroughDef()), get distinct

    [26 lines not shown]
DeltaFile
+479-0llvm/test/CodeGen/X86/regallocfast-inline-asm-fold-pressure.mir
+320-0llvm/lib/CodeGen/RegAllocFast.cpp
+80-0llvm/test/CodeGen/X86/regallocfast-inline-asm-fold.mir
+879-03 files

LLVM/project 7775e28 — llvm/lib/CodeGen/GlobalISel InlineAsmLowering.cpp, llvm/lib/CodeGen/SelectionDAG SelectionDAGBuilder.cpp

[CodeGen] Address review: error for "=m|r" direct outputs too

A direct output whose chosen alternative is memory, e.g. "=m|r", still
crashed SelectionDAG, which exempted multiple-alternative operands from the
check and then asked for the address of an output with no value. Drop the
exemption and test "=m|r" with both instruction selectors. Name the
selector explicitly in the RUN lines rather than relying on -O levels,
since X86 GlobalISel can't lower inline asm and both X86 lines ran
SelectionDAG anyway. Drop "yet" from the error: Clang never emits a
direct memory output, so there are no plans to support one.

Assisted-by: Claude Opus 5.5
DeltaFile
+14-10llvm/test/CodeGen/X86/inline-asm-direct-mem-output-error.ll
+11-3llvm/test/CodeGen/AArch64/inline-asm-direct-mem-output-error.ll
+5-4llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
+1-1llvm/lib/CodeGen/GlobalISel/InlineAsmLowering.cpp
+31-184 files

LLVM/project ad733e8 — llvm/lib/CodeGen/GlobalISel InlineAsmLowering.cpp, llvm/lib/CodeGen/SelectionDAG SelectionDAGBuilder.cpp

[CodeGen] Report an error for a direct inline asm output in memory

An inline asm output returned by value has no memory to write to, yet a
constraint such as "=rm" picks memory, the most general constraint, as
does "=m". SelectionDAG asserted on that ("Can only indirectify direct
input operands!"), and GlobalISel dereferenced a null pointer. Clang
never emits such an output, since it passes the address of a memory
output, but other IR can. Report "cannot handle direct memory outputs
yet for constraint 'm'" instead, like the other inline asm errors there.

Assisted-by: Claude Opus 5.5
DeltaFile
+31-0llvm/test/CodeGen/X86/inline-asm-direct-mem-output-error.ll
+16-6llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
+13-0llvm/test/CodeGen/AArch64/inline-asm-direct-mem-output-error.ll
+10-0llvm/lib/CodeGen/GlobalISel/InlineAsmLowering.cpp
+70-64 files

LLVM/project 8bcccd8 — mlir/include/mlir/IR OperationSupport.h, mlir/lib/IR AsmPrinter.cpp

[MLIR][AsmPrinter] Add alwaysUseAliases printing flag (#232518)

Per-function IR dumps print a nested op, which takes the non top-level
path where types and attributes expand in full. For passes over
functions with heavy types this buries the dump in noise that aliases
would fold away.

Add OpPrintingFlags::alwaysUseAliases plus the
mlir-print-always-use-aliases tool option. When set, printing
initializes aliases and takes the top-level path for any op, so nested
dumps use aliases. The flag takes precedence over local scope on
purpose: pass instrumentation prints nested ops with local scope, so
without precedence the per-function dumps this flag targets would never
use aliases.

Reusing one AsmState across prints must not carry the previous op
aliases or dialect resources into the next print, so initialize now
starts both fresh.

Assisted-by: Muse Code (Muse)
DeltaFile
+29-4mlir/lib/IR/AsmPrinter.cpp
+20-0mlir/test/Pass/ir-printing-always-use-aliases.mlir
+13-0mlir/include/mlir/IR/OperationSupport.h
+62-43 files

LLVM/project 843c021 — clang/lib/Headers riscv_packed_simd.h, clang/test/CodeGen/RISCV rvp-intrinsics.c

[RISCV][P-ext] Add missing packed pair (#232202)

Add missing v2i32 packed pair intrinsics.
DeltaFile
+104-0clang/test/CodeGen/RISCV/rvp-intrinsics.c
+58-0llvm/test/CodeGen/RISCV/rvp-simd-64.ll
+56-0cross-project-tests/intrinsic-header-tests/riscv_packed_simd.c
+9-1clang/lib/Headers/riscv_packed_simd.h
+3-3llvm/lib/Target/RISCV/RISCVISelLowering.cpp
+4-0llvm/lib/Target/RISCV/RISCVInstrInfoP.td
+234-46 files

LLVM/project 9ce13e3 — llvm/test/CodeGen/X86 greedy-inline-asm-fold.mir

[TargetInstrInfo] Address review: autogenerate greedy-inline-asm-fold.mir checks

Generate the checks with update_mir_test_checks.py so that the spills and
reloads around each folded inline asm are verified, not just the INLINEASM
itself. Fix the "=r" comment to describe the C "+r" operand, note that which
"+rm" pair greedy folds is its own choice, and add a "+&rm" case on an
uninitialized value showing that folding a pair whose tied use is undef
stores to the slot without loading from it.

Assisted-by: Claude Opus 5.5
DeltaFile
+94-8llvm/test/CodeGen/X86/greedy-inline-asm-fold.mir
+94-81 files

LLVM/project ec94ac5 — llvm/include/llvm/ADT APFloat.h, llvm/lib/Support APFloat.cpp

[APFloat][NFCI] Move x87DoubleExtended next to the other native IEEE types (#223193)

Reordered the `APFloatBase::Semantics` so that `S_x87DoubleExtended` is
placed after the IEEE types and before the DoubleDouble types.

Previously, `S_x87DoubleExtended` was the very last `enum` value,
meaning that `SemanticsToEnum`/`bitcastToAPInt`/`initFromAPInt` would
test if `Sem` is one of the 13 GPU floating point types before testing
if `Sem` is `x87DoubleExtended`. Given that `x87DoubleExtended` is more
commonly used and a native LLVM IR type, I thought a better heuristic
would be to test if `Sem` is a `x87DoubleExtended` type before testing
if it is one of the 13 GPU floating point types.

I also made the order of other functions/fields more consistent across
`APFloat`.
DeltaFile
+26-25llvm/lib/Support/APFloat.cpp
+13-13mlir/test/Conversion/ArithAndMathToAPFloat/arith-to-apfloat.mlir
+9-9llvm/include/llvm/ADT/APFloat.h
+6-6mlir/test/Conversion/ArithAndMathToAPFloat/math-to-apfloat.mlir
+54-534 files

LLVM/project 57441a2 — clang/test/CIR/CodeGen sve-vector-arith-ops.c, clang/test/CodeGen arm_neon_intrinsics.c

Merge branch 'main' into revert-231420-users/arsenm/clang/reapply-targetid-parsing-amdgpu-targetparser
DeltaFile
+1,461-0clang/test/CIR/CodeGen/sve-vector-arith-ops.c
+324-324clang/test/CodeGen/arm_neon_intrinsics.c
+224-356llvm/test/CodeGen/AMDGPU/llvm.is.fpclass.f16.ll
+490-0mlir/lib/Conversion/OpenACCToLLVM/ACCKernelLaunchPatterns.cpp
+437-3llvm/test/Transforms/SLPVectorizer/AArch64/or-reduction-byte-pack.ll
+435-0mlir/test/Conversion/OpenACCToLLVM/kernel-launch.mlir
+3,371-683161 files not shown
+7,826-2,119167 files

LLVM/project f2b77e8 — llvm/lib/CodeGen/SelectionDAG TargetLowering.cpp, llvm/test/CodeGen/X86 asm-constraints-rm-callbr-fold.ll asm-constraints-rm-isel.ll

[TargetLowering][X86] Prefer 'r' over 'm' for foldable "rm" inline asm operands

An "rm" (register-or-memory) inline asm operand has always resolved to
'm', because getConstraintPreferences() picks the most general
constraint present, and 'm' is more general than 'r'. That's safe, since
memory can't run out, but it forces a value that could stay in a
register through a stack slot even when there's no register pressure
(https://github.com/llvm/llvm-project/issues/20571).

Prefer 'r' instead where the register allocator can fold the register
back to a stack slot when it runs out of registers, and mark the
register operand foldable (InlineAsm::Flag::setRegMayBeFolded()) so it
does. Both allocators can: the greedy allocator folds an operand when it
spills its value, and the fast allocator folds operands up front when
the asm's register operands wouldn't fit.

ParseConstraints() sets AsmOperandInfo::MayFoldRegister for an operand
whose constraint codes include 'r' and 'm' and are otherwise only
immediate codes, above -O0, on a target that opts in through the new

    [26 lines not shown]
DeltaFile
+788-0llvm/test/CodeGen/X86/asm-constraints-rm-pressure.ll
+767-0llvm/test/CodeGen/X86/asm-constraints-torture.ll
+227-0llvm/test/CodeGen/X86/inline-asm-callbase.ll
+157-0llvm/test/CodeGen/X86/asm-constraints-rm-isel.ll
+73-2llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp
+74-0llvm/test/CodeGen/X86/asm-constraints-rm-callbr-fold.ll
+2,086-29 files not shown
+2,169-1615 files

LLVM/project 6ee8cbc — llvm/lib/CodeGen RegAllocFast.cpp, llvm/test/CodeGen/X86 regallocfast-inline-asm-fold.mir regallocfast-inline-asm-fold-pressure.mir

[RegAllocFast] Fold foldable inline asm operands under register pressure

An inline asm register operand marked foldable (from an "rm" constraint)
may be replaced with a stack slot when the register allocator runs out
of registers. The greedy allocator does that when it spills the value.
The fast allocator can't: it assigns the operands of an instruction one
at a time, and folding replaces the instruction. So it reported
"inline assembly requires more registers than available" instead.

Before allocating a block, estimate from each inline asm's own operands
whether they fit in registers, and fold as many foldable registers as
needed to make them fit, so the common case without pressure still gets
a register. Values that only live across the asm don't count, since the
allocator spills them when it needs their registers. The estimate
follows allocateInstruction():

- First all defs get distinct registers, avoiding physreg defs; then all
  uses, along with the defs still occupied while the uses are read
  (early-clobber and tied defs, see isLiveThroughDef()), get distinct

    [26 lines not shown]
DeltaFile
+479-0llvm/test/CodeGen/X86/regallocfast-inline-asm-fold-pressure.mir
+320-0llvm/lib/CodeGen/RegAllocFast.cpp
+80-0llvm/test/CodeGen/X86/regallocfast-inline-asm-fold.mir
+879-03 files

LLVM/project 1d7b2ca — llvm/lib/CodeGen/GlobalISel InlineAsmLowering.cpp, llvm/lib/CodeGen/SelectionDAG SelectionDAGBuilder.cpp

[CodeGen] Report an error for a direct inline asm output in memory

An inline asm output returned by value has no memory to write to, yet a
constraint such as "=rm" picks memory, the most general constraint, as
does "=m". SelectionDAG asserted on that ("Can only indirectify direct
input operands!"), and GlobalISel dereferenced a null pointer. Clang
never emits such an output, since it passes the address of a memory
output, but other IR can. Report "cannot handle direct memory outputs
yet for constraint 'm'" instead, like the other inline asm errors there.

Assisted-by: Claude Opus 5.5
DeltaFile
+31-0llvm/test/CodeGen/X86/inline-asm-direct-mem-output-error.ll
+16-6llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
+13-0llvm/test/CodeGen/AArch64/inline-asm-direct-mem-output-error.ll
+10-0llvm/lib/CodeGen/GlobalISel/InlineAsmLowering.cpp
+70-64 files

LLVM/project cd89df6 — llvm/lib/CodeGen TargetInstrInfo.cpp, llvm/test/CodeGen/X86 greedy-inline-asm-fold.mir

[TargetInstrInfo] Fix folding inline asm operands next to tied operands

foldInlineAsmMemOperand() swapped a register operand for the target's
memory operands with MachineInstr::removeOperand(), which asserts when a
later operand is tied, because moving it would break the tie. Inline asm
lists every input after every output, so folding any operand that comes
before another tied pair asserted, e.g. an "rm" input followed by the
input of a "+r" operand, or one of two "+rm" operands. Without
assertions, the moved operands kept stale tie indices. Untie the
operands, rebuild the operand list, and re-tie the remaining pairs at
their new positions.

It also gave up when the register appears in more than one operand, e.g.
one value passed to two "rm" operands, which left the greedy allocator
unable to spill that value at all. Fold every such operand into the
stack slot.

Finally, take MayLoad from the folded operands rather than from every
read of the register: a folded def whose tied use is another virtual

    [9 lines not shown]
DeltaFile
+85-32llvm/lib/CodeGen/TargetInstrInfo.cpp
+108-0llvm/test/CodeGen/X86/greedy-inline-asm-fold.mir
+193-322 files

LLVM/project 460301f — llvm/lib/DebugInfo/DWARF DWARFUnitIndex.cpp, llvm/test/DebugInfo/X86 invalid-cu-index-full-dwp.s

[DebugInfo] Bound the probe loop in DWARFUnitIndex::getFromHash (#232375)

A CU/TU index with no empty slot and no matching signature made the
lookup iterate forever. Stop after NumBuckets probes, which visit every
slot of a well-formed table.

rdar://186841022
DeltaFile
+58-0llvm/test/DebugInfo/X86/invalid-cu-index-full-dwp.s
+10-9llvm/lib/DebugInfo/DWARF/DWARFUnitIndex.cpp
+68-92 files

LLVM/project 6ff9eef — llvm/include/llvm/IR InlineAsm.h, llvm/lib/CodeGen MIRPrinter.cpp

[MIR] Serialize the "foldable" inline asm register operand flag (#229626)

The symbolic MIR syntax for inline asm operand flags dropped
InlineAsm::Flag's RegMayBeFolded bit, which marks a register operand
(from an "rm" constraint) that the register allocator may fold to a
stack slot. Printing MIR and parsing it back therefore silently changed
what the allocator was allowed to do, e.g. with -stop-before and
-run-pass, and a test could only set the bit through a raw numeric flag.

Print the bit as a trailing "foldable", as MachineInstr::print() already
does, and parse it back. A tied use stores its matched operand number in
the same bits, so it never prints the marker.

Co-authored-by: Nick Desaulniers <ndesaulniers at google.com>
Co-authored-by: Bill Wendling <morbo at google.com>
DeltaFile
+62-53llvm/lib/CodeGen/MIRParser/MIParser.cpp
+23-0llvm/test/CodeGen/MIR/X86/inline-asm-foldable.mir
+11-0llvm/test/CodeGen/MIR/Generic/inline-asm-foldable-not-reg.mir
+6-3llvm/lib/CodeGen/MIRPrinter.cpp
+7-0llvm/include/llvm/IR/InlineAsm.h
+109-565 files