-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Minor simplification to FixedWidthInteger._random(using: &generator)
.
#27056
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
Closed
stephentyrone
wants to merge
2
commits into
swiftlang:master
from
stephentyrone:random-simplification
Closed
Changes from all commits
Commits
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
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.
The validation-test uses
swift_stdlib_random
with buffers larger than aUInt64
.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.
Also
arc4random_buf
uses the C calling conv.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.
And you can't use
@_silgen_name
to declare arbitrary C things regardless, because they'll collide with the real declarations at the SIL level when someone imports them.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.
If
swift_stdlib_random
(for__APPLE__
platforms) was moved from Random.cpp to Random.h, usingstatic inline SWIFT_ALWAYS_INLINE
, would it be imported into Swift as@inlinable
?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.
Yeah, we do this in a bunch of other places, and it's also (almost) what I'll do here. I'll update this sometime this week. (We can't quite just make the function
static inline
, because we need to still have an external symbol to support code compiled with an earlier version of Swift, but that's easy enough to address.)Minor note: it's not semantically equivalent to
@inlinable
--it has the semantics of a C[++] always-inline function.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.
Is your contention that we shouldn't have any such static inline wrappers in the shims? If so, what's the alternative--just eat the performance hit for all of these operations? For random there's enough work happening that it's not catastrophic, but it's still measurable, and for some of these other operations it's worse.
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.
The rule is that the static ones can't call anything declared elsewhere. We've been eating the perf hit where the indirection is used for several releases; we can take a little longer to come up with a proper solution (or figure out how to compile with LTO).
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.
This problem is also specific to the standard library, because that's the only library that's below the $Platform module.
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.
Except for
strlen
andmemcmp
(both of which actually have clang builtins, IIRC, so I think we could fix those) andmalloc_size
andfree
and ...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 looks like I was tagged into #19614 and didn't complain then. I do not trust any of this though—the types are only matching up because the importer special-cases a few of the shims types like it does the real libc types, and the more we do it the more likely we are to accidentally diverge from the real SDK.