Fix the Swift calling convention patches for RISC-V, MIPS and 32-bit PowerPC - #32
Merged
Merged
Conversation
RISC-V 64 needs no toolchain patch to build - RISCVTargetCodeGenInfo already registers a SwiftABIInfo upstream - so it is not held back the way MIPS and 32-bit PowerPC are. Restore dispatch, Foundation and the library packages so it matches every other supported architecture.
It builds with a stock clang - RISCVTargetCodeGenInfo already registers a SwiftABIInfo upstream - so it needs neither the from-source toolchain this workflow exists for nor the hand-run cadence. MIPS and 32-bit PowerPC still do.
Promotes RISC-V 64 to a gating architecture: it builds with the prebuilt toolchain like the rest of the matrix, and swift-define already falls through to qemu-riscv64-static, so build-test.sh runs it under qemu.
The push workflow runs each architecture in colemancda/buildroot-swift:swift_<arch>_defconfig, so riscv64 needs its image published alongside the others.
colemancda
force-pushed
the
feature/riscv64-supported
branch
from
August 1, 2026 09:45
b8ca392 to
588f8d3
Compare
riscv64 does not build: clang drops the Swift calling convention for RISC-V and every SWIFT_CONTEXT parameter in the runtime headers then fails to compile. Put it back where it was - stdlib-only defconfig, out of the push and docker matrices, in the experimental workflow - until a clang patch lands alongside the MIPS and 32-bit PowerPC ones.
Building the stdlib for riscv64 stops in the runtime headers with 'swift_context' parameter can only be used with swiftcall or swiftasynccall calling convention RISCVTargetCodeGenInfo does register a SwiftABIInfo, which is what the README took for the whole story, but the two halves around it are missing: sema never accepts the attribute for RISC-V, so it is dropped and the default convention substituted, and the backend has no case for CallingConv::Swift in LowerFormalArguments. Add both, the same way MIPS and 32-bit PowerPC carry their own patches.
The registered SwiftABIInfo is only the CodeGen half; sema and the backend both reject the convention, so RISC-V sits with MIPS and 32-bit PowerPC rather than apart from them.
colemancda
changed the title
The patch registered a SwiftABIInfo but nothing ever reached it: MipsTargetInfo does not override checkCallingConvention, so sema inherits the base version accepting only CC_C, drops swiftcall and substitutes the default convention. The build then fails on the first SWIFT_CONTEXT parameter in the runtime headers, exactly as riscv64 does. Accept CC_Swift, and refuse CC_SwiftAsync the way PPC64 does so swift's Config.h falls back to SWIFT_CC(swift) for it.
Same gap as MIPS: the checkCallingConvention override in PPC.h belongs to PPC64TargetInfo, so ppc64le accepts swiftcall while PPC32TargetInfo inherits the base version and drops it before CodeGen sees it. Mirror PPC64's table for the 32-bit target.
colemancda
changed the title
All three are now the same change filed against llvm/llvm-project, so the buildroot copies, the swiftlang fork PRs and the upstream PRs carry identical code: MIPS llvm/llvm-project#213446 PPC32 llvm/llvm-project#213447 RISC-V llvm/llvm-project#213448 Two behaviour changes fall out of that. The sema tables keep CC_C returning CCCR_OK, which the earlier versions dropped - an override replaces the base implementation wholesale, so omitting it would have started warning on an explicit cdecl. And RISC-V now refuses CC_SwiftAsync like MIPS and PPC32 rather than accepting it, since lowering it needs guaranteed tail calls the backend does not provide; swift's Config.h falls back to SWIFT_CC(swift) on its own.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Supersedes the promotion this branch started as. riscv64 does not build, and chasing that turned up the same defect in the MIPS and 32-bit PowerPC patches already on master: all three teach clang's CodeGen about the Swift calling convention but never teach sema, so the attribute is dropped before CodeGen is ever reached.
What actually fails
Building the stdlib for riscv64 stops in the runtime headers:
Sema asks
TargetInfo::checkCallingConventionwhether the target takesCC_Swift.MipsTargetInfo,PPC32TargetInfoandRISCVTargetInfoall answer no - the first two by inheriting the base version that accepts onlyCC_C, the third by omitting the case from its own table. Sema then dropsswiftcallwith a warning that the stdlib's-whides, and everySWIFT_CONTEXTparameter becomes a hard error. A registeredSwiftABIInfonever gets a say.Reproducible without buildroot, against swiftlang's own clang:
swiftcallswiftasynccallppc64le is green today because swift's
Runtime/Config.hguards the two conventions asymmetrically:SWIFT_CC_swiftasyncsits behind__has_extension(swiftasynccc), which is derived fromcheckCallingConventionand so is target-aware, and falls back toSWIFT_CC(swift).SWIFT_CC_swiftsits behind__has_attribute(swiftcall), which is target-independent and always true - the attribute is emitted, silently dropped, and onlySWIFT_CONTEXTreveals it. The header carries aFIXME: the next comment is falseright above that block.Changes
0003-clang-Add-Swift-support-for-RISC-V.patch(new) - accept both conventions in sema; addCallingConv::Swift/SwiftTailtoRISCVTargetLowering::LowerFormalArguments, which would otherwisereport_fatal_error("Unsupported calling convention"). The CodeGen half is already upstream for RISC-V.0001and0002- add the missing sema half for MIPS and 32-bit PowerPC, mirroringPPC64TargetInfo's table. RefusingCC_SwiftAsyncis deliberate: it makesConfig.hfall back toSWIFT_CC(swift)rather than emit a convention the backend cannot lower.None of these need a separate assignment function -
CC_RISCVand the PPC32/MIPS C conventions are reused, withSwiftErrorInRegisterfalse so the error is passed indirectly.Not yet verified
All three patches apply cleanly and in sequence to
swift-6.3.3-RELEASE(patch -p1, no fuzz or offsets), and the diagnosis reproduces against swiftlang's clang. None of them have been compiled: they only take effect in a toolchain built from source, so proving them means an experimental-workflow run with atoolchain_urlthat carries them. The upstream PRs cited in0001and0002contain only the CodeGen half; the sema half is not upstream anywhere yet.