-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Use runtime helper CreateSpan
for stackalloc
of non-byte arrays
#71261
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
Show all changes
18 commits
Select commit
Hold shift + click to select a range
b452022
Optimize non-byte stackalloc scenarios
jjonescz 7407247
Inline a variable
jjonescz 4375e44
Inline a method
jjonescz b262c1c
Use Binder helper to get well-known member
jjonescz 23ff1d9
Visit everything in local rewriter
jjonescz e60c214
Clarify comment
jjonescz bf48b4b
Test non-blittable type
jjonescz 020f8b4
Fix nullability
jjonescz bacc7e0
Revert part that skips stack allocation
jjonescz 750dfb7
Align the data field
jjonescz 1dd6d14
Test zero elements
jjonescz a3678b8
Use indexer instead of `GetPinnableReference`
jjonescz f337c1f
Reuse `IsTypeAllowedInBlobWrapper`
jjonescz 5372ee1
Emit `unaligned.` prefix
jjonescz 83f37e7
Test 2-byte primitive
jjonescz ae76846
Align to 8 bytes and omit `unaligned.` IL
jjonescz 14d9740
Revert "Align to 8 bytes and omit `unaligned.` IL"
jjonescz 3cd394b
Merge branch 'main' into 69325-stackalloc-NonByte
jjonescz File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at the
unaligned.
section of ECMA-335From that, I infer that, if we align the RVA field type at 8 bytes, we will be compliant without the
unaligned
prefix. Should we use that option instead, rather than having conditional IL?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are there any downsides to conditional IL? On the other hand, it seems that aligning properly to 1/2/4/8 bytes instead of always to 8 bytes saves space.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IL is bigger. Compiler's code is more complex. Test matrix is bigger, more scenarios need special attention.
I do not think it actually does. At least not for the code emitted by our compilers because, I think, compiler aligns all blobs at 8 bytes regardless of the requested alignment, this is mentioned in one of the comments in code. The alignment that we explicitly set on the types is important for IL rewriting scenarios.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this means it improves size for AOT and similar precompiled code (right?) which seems important as well.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be honest, I do not know the answer to these questions, And, even if that was the case, I am not sure if that is something that we should care about.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not think it makes sense to deoptimize the 1-byte case like that.
To make the two cases as similar as possible, you can emit
unaligned.1 cpblk
in both cases and emit the blob withelementType.EnumUnderlyingTypeOrSelf().SpecialType.SizeInBytes()
alignment in both cases.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is what I would do. I would align both at 8 bytes explicitly (we are aligning blobs at 8 bytes regardless), and would completely get rid of the
.unaligned
instruction.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is size de-optimization for trimmer and AOT that are scenarios where we care about the side the most.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps I misinterpreted you first message on this discussion thread.
If the blob size optimization is important for AOT, then, I think we should keep the
.unaligned
usage on both code paths. We can get there by reverting the last commit. Sorry for the confusion.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was commenting on why we set the alignment and why it would not work to omit it on the types. Sorry for the confusion.