SILGen: improve code generation for array literals #84795
Merged
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
eeckstein
requested review from
AnthonyLatsis,
Xazax-hun,
asl,
egorzhdan,
fahadnayyar,
hnrklssn,
j-hui,
jckarter,
kavon,
rjmccall,
susmonteiro and
zoecarver
as code owners
eeckstein
requested review from
aidan-hall,
atrick,
kovdan01,
lorentey,
meg-gupta and
nate-chandler
and removed request for
AnthonyLatsis,
Xazax-hun,
egorzhdan,
fahadnayyar,
hnrklssn,
j-hui,
susmonteiro and
zoecarver
|
@swift-ci smoke test |
|
@swift-ci apple silicon benchmark |
asl
reviewed
Oct 9, 2025
| // DEBUG-NEXT: [AD] Adjoint for the following value is a projection, skipping: %[[#D4:]] = pointer_to_address %[[#D5:]] : $Builtin.RawPointer to [strict] $*Float | ||
| // DEBUG-NEXT: [AD] The following active value is loop-local, zeroing its adjoint value in loop header: %[[#D6:]] = apply %[[#]]<Float>(%[[#D2]]) : $@convention(thin) <τ_0_0> (@owned Array<τ_0_0>) -> @owned Array<τ_0_0> | ||
| // DEBUG-NEXT: [AD] Setting adjoint value for %[[#D6]] = apply %[[#]]<Float>(%[[#D2]]) : $@convention(thin) <τ_0_0> (@owned Array<τ_0_0>) -> @owned Array<τ_0_0> | ||
|
|
There was a problem hiding this comment.
@kovdan01 Will you please double check that this is expected result here given the change of SIL for array literals?
eeckstein
force-pushed
the
array-initialization
branch
from
338bbd6 to
221d2e8
Compare
eeckstein
force-pushed
the
array-initialization
branch
from
221d2e8 to
5fa3183
Compare
|
@swift-ci test |
|
@swift-ci apple silicon benchmark |
It used to be done with a library intrinsic which returns the array and an element address pointer. A `mark_dependence` was used to "connect" the two results. But this resulted in completely wrong OSSA after inlining. It just didn't get caught be the verifier because the SIL was obfuscated by address-pointer conversions. Now we don't use the second result (= the element address) of the intrinsic but generate a correct borrow scope from the first (= array) result. Within that borrow scope we project out the element address with a `ref_tail_addr` instruction. This relies on knowledge of the internal Array data structures. However those data structures are baked into the ABI since a long time and will not change.
…_based_sendability.swift TODO: fix handling of Array initialization in the SendNonSenable pass
…e ForEachLoopUnroll pass
…e ArrayCountPropagation pass
This benchmark just wants to test if stack promotion of an array literal works. This is so simple that it's better tested with a lit test.
eeckstein
force-pushed
the
array-initialization
branch
from
5fa3183 to
60efd32
Compare
|
@swift-ci smoke test |
|
LGTM Please update the PR description as discussed:
OSLogOptimization also generates the previous SILGen pattern - This may need to be updated as well. |
As this is not actually causing a miscompile, I'll leave that open for future work |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
It used to be done with a library intrinsic which returns the array and an element address pointer. A
mark_dependencewas used to "connect" the two results.But the pointer was obtained from a wrong borrow scope and from a wrong copy of the buffer. This resulted in completely wrong OSSA after inlining. It just didn't get caught by the verifier because the SIL was obfuscated by address-pointer conversions.
Now we don't use the second result (= the element address) of the intrinsic but generate a correct borrow scope from the first (= array) result. Within that borrow scope we project out the element address with a
ref_tail_addrinstruction.This relies on knowledge of the internal Array data structures. However those data structures are baked into the ABI since a long time and will not change.