-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Improve SIMD type element count validation #80652
Conversation
…limit SIMD vector lengths.
r? @estebank (rust-highfive has picked a reviewer for you, use r? to override) |
65536, or a 16-bit value, was chosen "arbitrarily". Allow me to provide a justification, even if it is a mere post hoc rationale: Rust supports byte (as in octet) addressing, and it is reasonable to say something like "a SIMD vector supported in a programming language should be fully addressable at the same level as the language". In addition, most SIMD vectors let you use byte-size lanes in hardware but few will go down to bits or even nybbles, so that is another angle which suggests we should focus on byte elements as our minimum. With a 16-bit number we could index every byte in a hypothetical 524,288-bit vector. This is 512*(2^10) bits, or 10 doublings past our current capability. Even the most gratuitous interpretations of Moore's law would suggest we would not be able to reach this in commodity hardware for another 20 years, and even supercomputers would take a while. For various reasons, in practice, vectors grow even more slowly than that, doubling in commodity hardware only every ~9 years or so (SSE for 128-bit vectors in 1999, AVX-512F in 2017). Even Arm SVE2 only allows a maximum vector length of 2048 bits, for which an 8-bit number is sufficient to index every byte. While a possible implementation of a hypothetical "extensible vector" ISA, like a further extension of SVE2 to "SVE2.1" or "SVE3", or even the current alpha of the RISCV-V design, on a... very beefy chip, even by supercomputer standards... may allow a hypothetical 2^19 bit monster-vector to live and breathe even before the next 20 years pass, I am nonetheless content with saying that this 65536 lane limitation does not impose an unnecessary limitation on the capabilities of the Rust compiler for any futures I expect Rust to remain relevant in. I would even support an 8-bit limitation for now with an eye towards eventually lifting it, as it would complicate handling 4096-bit vectors and thus could realistically be considered a limitation in meeting the capabilities of silicon that might be printed even in the lifetimes of mere mortals, as that exceeds the capacity of even the most ambitious ISAs, but by a realistic amount. Note that SVE2 itself is not publicly available on any cores I am aware of, so as far as I know, and things like masking operations will already run into amusing consequences on 2048-bit lanes as-is, so this itself is definitely not a limitation today, either. Finally, as noted in that issue, Cranelift supports 16-bit lane lengths. |
Regarding errors, I believe we should try to catch zero-lane vectors specially if we can. Philosophically, the minimum number of lanes for a "SIMD" operation to make sense is not 0 or even 1, but 2. |
r? @nagisa |
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.
Overall looks pretty good to me I have a couple comments in-line but nothing major.
@bors try
@bors try |
⌛ Trying commit 07db2bf with merge 84b21bfb06d318b7a01ab0f0a70d0190ffbca05e... |
☀️ Try build successful - checks-actions |
…SIMD vectors with non-power-of-two lengths.
In the last stdsimd meeting we decided it would be best to limit Since |
The job Click to see the possible cause of the failure (guessed by this bot)
|
The job Click to see the possible cause of the failure (guessed by this bot)
|
The job Click to see the possible cause of the failure (guessed by this bot)
|
@bors try |
⌛ Trying commit a4bab7c with merge aed835460397ceb814007e0d97479d7c98844d78... |
☀️ Try build successful - checks-actions |
@craterbot check We'd like to do a crater run to see what the impact of our changes to |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
Given that vek only uses |
That sounds like a good plan, if that sounds good to everyone I can open an issue over there. |
Remember that this is nightly-only, so any forewarning about breakage is just about being nice, not required. Something like opening an issue on their repos now then merging a week or later sounds more than sufficient to me. |
|
@bors r+ rollup=never |
📌 Commit a4bab7c has been approved by |
☀️ Test successful - checks-actions |
Tested on commit rust-lang/rust@bb587b1. Direct link to PR: <rust-lang/rust#80652> 💔 miri on windows: test-pass → test-fail (cc @oli-obk @eddyb @RalfJung). 💔 miri on linux: test-pass → test-fail (cc @oli-obk @eddyb @RalfJung).
Are you leaking this behavior to stable or does it require unstable features to trigger? Preventing post-monomorphization errors here is definitely possible and desirable |
|
Resolves rust-lang/portable-simd#53.
These changes are motivated by
stdsimd
moving in the direction of const generic vectors, e.g.:This makes a few changes:
usize::MAX
, at least.Unresolved questions:
LayoutError
or otherwise provide context in some way? As it stands, users ofstdsimd
could trivially produce monomorphization errors by making zero-length vectors.cc @bjorn3