AtomicExpand: Use RuntimeLibcallsInfo signatures for atomic libcalls (#238972)
Take the function type and attributes of the emitted __atomic_* calls
from RuntimeLibcallsInfo instead of building them by hand.
This fixes missing extension attributes on the value operand and
result of the sized variants, which are unsigned integers of the
access size. On targets whose C ABI extends narrow integer arguments,
such as RISC-V and ARM, the callee could see unextended high bits. i8
and i16 values now get zeroext, and i32 values get signext on
RV64. Callers can also rely on the extended return value, which
removes redundant extensions after some calls.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
ARM: Remove dead kill flag maintenance in MVETPAndVPTOptimisations
This pass runs before register allocation, and the verifier now
rejects kill flags on virtual registers.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
AArch64: Remove dead kill flag maintenance in AArch64PostCoalescer
The sources of the transposed tuple pseudos are virtual registers,
which can no longer carry kill flags.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
EarlyIfConversion: Remove dead kill flag maintenance
The verifier now rejects kill flags on virtual registers, so there are
never repeated kills of a virtual register in the two sides of a
diamond to clear.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
MachineVerifier: Disallow kill flags on virtual registers
Kill flags are deprecated, and nothing introduces them on virtual
registers anymore. Reject them in the verifier to prevent new uses
from creeping back in. Kill flags on physical registers are still
permitted. There are still some lingering post-RA kill flag reliance.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
CodeGen: Handle uses in unreachable blocks in LiveIntervals
Previously LiveIntervals had the unenforced assumption that the
function does not contain any unreachable blocks. A register which had
a definition somewhere but also a use in an unreachable block would
hit a "Use not jointly dominated by defs" assertion.
Avoiding no-unreachable-blocks as a hard requirement avoids assertions
in some pass configuration edge cases. In particular when the
MachinePipeliner is enabled in an optimized pipeline there could still
be unreachable blocks in an optnone function which would hit the
assert. Not handling unreachable blocks was also a large problem for
llvm-reduce's MIR support and was one of the main obstacles to landing
a basic block reduction.
Give a value live into an unreachable block a phi-def at the start of
the block, using the dominator tree to identify unreachable blocks.
ConnectedVNInfoEqClasses::Classify joins a component made only of
phi-defs in unreachable blocks with a component that has a real def;
[6 lines not shown]
[CIR] Make LoweringPrepare safe to rerun on C++20 module units (#237395)
LoweringPrepare builds the initializer of a C++20 module interface unit
from the 'cir.cxx_module_init_fn_name' and 'cir.cxx_module_imported_inits'
module attributes, but left them in place. Running the pass again on its
own output, e.g. on an emitted .cir file, rebuilt the initializer and asserted
with "function already has an entry block".
Drop both attributes once the initializer is built. This related to:
https://github.com/llvm/llvm-project/pull/234013
[CIR] Make LoweringPrepare safe to rerun on TLS globals (#237376)
LoweringPrepare builds the wrapper (`_ZTW*`) and init alias (`_ZTH*`) of
each thread-local global from its `tls_refs` attribute, but leaves the
attribute in place. Running the pass again on its own output, e.g. on an emitted
`.cir` file, rebuilds the wrappers and fails:
```
error: redefinition of symbol named '_ZTW2tl'
```
This was partially discovered in this discussion: #234013 . The solution
is to drop the `tls_refs` attribute after the pass consumes it.
[clang][CodeGen] Emit callee_type metadata for all indirect calls
CodeGenFunction::EmitCall only attached the call graph section callee_type
metadata to an indirect call when its caller asked for the emitted call
instruction through the callOrInvoke out parameter, because the emission
was nested in the block that stores it. Indirect calls emitted by callers
that do not pass callOrInvoke, such as the virtual destructor call of a
delete expression (emitVirtualObjectDelete -> EmitCXXDestructorCall), got
no callee_type metadata and therefore no indirect callee type identifiers
in the .llvm.callgraph section, so the call graph missed those edges.
Attach the metadata to the emitted call instruction regardless of whether
the caller asked for it.
Stacked on #230831.
Assisted-by: Claude
[clang][CodeGen] Identify virtual methods by their override chain root in the call graph section
A virtual call site is typed after the method named at the call site, but it
can reach any overrider of that method, and overriders may differ from it in
their covariant return type. In that case the `!callee_type` identifier of a
call through a base class pointer did not match the `!callgraph` identifier
of the overrider, and the call graph section missed the edge.
Identify every method of an override chain, at definitions, call sites and
thunks, by the type of the method that introduced the virtual function, so
that virtual calls through a pointer to any class of the hierarchy match the
overriders they can reach.
Stacked on #230838.
Assisted-by: Claude
[clang][CodeGen] Use the primary base chain for virtual method IDs
Identify a virtual method in the call graph section after the method it
overrides along the primary base chain of its class, as given by the record
layout. That is the vtable entry the method is placed in, which is not always
the first method it overrides.
Assisted-by: Claude
[clang][CodeGen] Attach a single callgraph type identifier to function definitions (#230838)
A function definition is annotated with its call graph section type identifier
twice, when its declaration is created (SetFunctionAttributes) and when its
body is emitted (SetLLVMFunctionAttributesForDefinition), so every
defined function carries two identical `!callgraph` attachments:
define void @foo() #0 !callgraph !3 !callgraph !3 {
Replace the attachment instead of adding a second one, so that a
function carries exactly one identifier. The `.llvm.callgraph` section is
unaffected, the AsmPrinter only uses the first identifier of a function.
Assisted-by: Claude
SafeStack: Use RuntimeLibcallsInfo signatures for libcalls
Take the function type, attributes and calling convention of
__stack_chk_fail and __safestack_pointer_address from RuntimeLibcallsInfo
instead of constructing them by hand. These now use arm_aapcscc on AAPCS
targets.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[NFC] Update check lines for nofpclass-multiunitfptype.ll (#238989)
Runs `update_test_checks.py` for `nofpclass-multiunitfptype.ll` since I
forgot to re-run them in
https://github.com/llvm/llvm-project/pull/223296
AMDGPU: Remove kill flags on virtual registers from MIR tests (#236977)
Soon the verifier will disallow this. Delete redundant tests which
only differed from others by kill flag uses. twoaddr-bundle.mir relied
on the input kill flags in TwoAddressInstruction, so compute
LiveIntervals first as the real pipeline does.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[mlir][OpenACC] Unwrap multi-block regions in ACCRegionUnwrapConversion (#236289)
Follow-up to #236052, reworked based on @razvanlupusoru's review.
`ACCRegionUnwrapConversion` inlines the region of a structured construct
like `acc.host_data` or `acc.data` into the parent block when
specializing for host or device. It asserted that the region has exactly
one block, but these ops accept any region, so a multi-block body
crashed `acc-specialize-for-host` and `acc-specialize-for-device`.
A multi-block region is now wrapped in `scf.execute_region` with the
existing `wrapMultiBlockRegionWithSCFExecuteRegion` utility, and an
empty region just erases the op. `acc-specialize-for-device` now
declares SCF as a dependent dialect, like `acc-specialize-for-host`
already does.
The canonicalizer still bails out on multi-block regions, so the OpenACC
dialect does not pick up a dependency on `cf`.
Fixes #236287
DwarfEHPrepare: Use RuntimeLibcallsInfo signature for the rewind libcall
Report an error if no rewind libcall is available, rather than
emitting a call to a function with an empty name.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[CIR] Pass the promise address to cir.coro.intrinsic.id (#236293)
CIRGen was emitting `cir.coro.intrinsic.id` with a null promise operand.
Classic codegen fills it in with the promise alloca once the promise
variable has been emitted. Do the same in CIRGen, bitcasting the promise
address to `!cir.ptr<!void>` to match the expected type.
AtomicExpand: Use RuntimeLibcallsInfo signatures for atomic libcalls
Take the function type and attributes of the emitted __atomic_* calls
from RuntimeLibcallsInfo instead of building them by hand.
This fixes missing extension attributes on the value operand and
result of the sized variants, which are unsigned integers of the
access size. On targets whose C ABI extends narrow integer arguments,
such as RISC-V and ARM, the callee could see unextended high bits. i8
and i16 values now get zeroext, and i32 values get signext on
RV64. Callers can also rely on the extended return value, which
removes redundant extensions after some calls.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
RuntimeLibcalls: Use <2 x i64> for i128 libcall types on Win64 (#238221)
Win64 passes __int128 by reference and returns it in XMM0. i128 uses
GPR pairs, and <2 x i64> uses the correct vector register. This
matches the type AtomicExpand and clang uses for these functions.
Also fix AtomicExpand to use the correct type for UEFI (which should
eventually use the type information in RuntimeLibcallsInfo).
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[lldb] Stop recognizing Swift mangled names in Mangled (#232930)
Currently Mangled recognizes Swift mangled names, even though LLDB on
llvm.org has no Swift support and can't demangle them.
This patch removes them, so that the Swift plugin can register a
proper Swift mangling scheme. On main, this means that Swift names are
now stored as plain names, which is how LLDB already displayed
them.
Assisted-by: Claude
Depends on: https://github.com/llvm/llvm-project/pull/232929
