SwiftCompilerSources/SIL: Fix APInt assertion failure on rebranch #84052
Conversation
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
AnthonyLatsis
requested review from
rjmccall,
jckarter and
eeckstein
as code owners
|
@swift-ci please test |
AnthonyLatsis
changed the title
|
@swift-ci please test macOS |
AnthonyLatsis
force-pushed
the
jepa-main2
branch
from
41b251d to
7e1bd8e
Compare
AnthonyLatsis
changed the title
|
@swift-ci please test |
eeckstein
reviewed
Sep 24, 2025
AnthonyLatsis
force-pushed
the
jepa-main2
branch
from
7e1bd8e to
59444b4
Compare
The assertion is hit through `TypeValueInst.simplify` when constructing an integer literal instruction with a negative 64-bit `Swift.Int` and a bit width of 32 (the target pointer bit width for arm64_32 watchOS). This happens because we tell the `llvm::APInt` constructor to treat the input integer as unsigned by default in `getAPInt`, and a negative 64-bit signed integer does not fit into 32 bits when interpreted as unsigned. Fix this by flipping the default signedness assumption for the Swift API and introducing a convenience method for constructing a 1-bit integer literal instruction, where the correct signedness assumption depends on whether you want to use 1 or -1 for 'true'. In the context of using an integer to construct an `llvm::APInt`, there are 2 other cases where signedness matters that come to mind: 1. A non-decimal integer literal narrower than 64 bits, such as `0xABCD`, is used. 2. The desired bit width is >64, since `llvm::APInt` can either zero-extend or sign-extend the 64-bit integer it accepts. Neither of these appear to be exercised in SwiftCompilerSources, and if we ever do, the caller should be responsible for either (1) appropriately extending the literal manually, e.g. `Int(Int16(bitPattern: 0xABCD))`, or (2) passing along the appropriate signedness.
AnthonyLatsis
force-pushed
the
jepa-main2
branch
from
59444b4 to
ac61901
Compare
|
@swift-ci please test |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The assertion is hit through
TypeValueInst.simplifywhen constructing an integer literal instruction with a negative 64-bitSwift.Intand a bit width of 32 (the target pointer bit width for arm64_32 watchOS). This happens because we tell thellvm::APIntconstructor to treat the input integer as unsigned by default ingetAPInt, and a negative 64-bit signed integer does not fit into 32 bits when interpreted as unsigned.Fix this by flipping the default signedness assumption for the Swift API and introducing a convenience method for constructing a 1-bit integer literal instruction, where the correct signedness assumption depends on whether you want to use 1 or -1 for 'true'.
In the context of using an integer to construct an
llvm::APInt, there are 2 other cases where signedness matters that come to mind:0xABCD, is used.llvm::APIntcan either zero-extend or sign-extend the 64-bit integer it accepts.Neither of these appear to be exercised in SwiftCompilerSources, and if we ever do, the caller should be responsible for either (1) appropriately extending the literal manually, e.g.
Int(Int16(bitPattern: 0xABCD)), or (2) passing along the appropriate signedness.