-
Notifications
You must be signed in to change notification settings - Fork 245
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
wasmparser
: feature gate Wasm simd
support
#1903
base: main
Are you sure you want to change the base?
Conversation
Thanks again for pushing on this! Overall this is roughly what I was thinking, and while I'm ok with the current state of it I think it's worth reviewing the final end-state as well when all the CI is passing and everything is hooked up (e.g. #[cfg]s are in place and compile-time-wins are remeasured and such)
Can this be fixed by marking
I'm not necessarily overly worried about this since simd instructions are likely a very small fraction of a larger module. Might be worth still trying to confirm one way or another, but I don't think it'd be the end of the world either way. When this might perhaps be an issue is with the GC proposal where if a similar strategy is taken for GC then that could have a significant impact since modules are probably all-GC or mostly-all-MVP for example.
I think it's pretty reasonable as is personally. There's two macros to invoke but they're both passed the same macro since they have the same syntax so while it's a bit more boilerplate that's sort of just par for the course with these sorts of refactorings and is a cost to acknowledge being placed on users where the benefit is being able to conditionally disable simd/etc. |
@alexcrichton Thank you for the preliminary review of the WIP PR. :)
I will be working on that now. I just wanted to know if the current structure is as you imagined which seems to be the case.
Should be possible indeed.
We only do all this acrobatics because there are so many
Okay thank you for your view on this. I agree! |
Oh, that is very interesting. So is it true that |
Oh not necessarily, and shared-everything-threads is still under development itself. While simd is a relatively obvious choice of "can split this off" I'm not sure if there are other reasonable things to split off in chunks at this time. |
@alexcrichton this PR is ready for a proper review now. |
wasmparser
: feature gate Wasm simd
support (WIP)wasmparser
: feature gate Wasm simd
support
@@ -76,7 +76,7 @@ impl<'cfg, 'wasm> Reencode for InitTranslator<'cfg, 'wasm> { | |||
O::RefNull { .. } | O::I32Const { value: 0 | 1 } | O::I64Const { value: 0 | 1 } => true, | |||
O::F32Const { value } => value.bits() == 0, | |||
O::F64Const { value } => value.bits() == 0, | |||
O::V128Const { value } => value.i128() == 0, | |||
O::Simd(SimdOperator::V128Const { value }) => value.i128() == 0, |
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 this again, what do you think of throwing all the simd ops back into Operator
? It's already #[non_exhaustive]
and would be nice to have a bit less churn as well in theory
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 am not yet sure if this works as intended due to the split into 2 macros and the problem that you cannot have macro invokation at enum variant definition position but I ll see how it goes. A downside to this approach is that this would result in tons of cfgs.
- This does not yet provide a for_each_operator macro in for !simd mode but that should be easily added. - This is WIP in that is currently does not handle the documentation of the macros well. We might need to also generate the macro docs in the macros themselves.
Closes #1899.
This allows to feature gate parsing and validation of all 268
simd
andrelaxed-simd
Wasm operators.Goals: improved compile times and reduced artifact size.
Summary
simd
andrelaxed-simd
definitions frommacro_rules! for_each_operator
.macro_rules! for_each_simd_operator
.SimdOperator
enum.VisitSimdOperator
trait.VisitOperator::simd_visitor
trait method with default implementation.simd
crate feature, gatingsimd
andrelaxed-simd
Wasm proposals support.Operator::Simd(SimdOperator)
variant.#[non_exhaustive]
onOperator
enum.Notes
BinaryReader
now is done via dynamic dispatch. Although it is likely that LLVM can optimize this. Benchmarks needed.wasmparser
as library is a bit more complex since we now have 2 generator macros instead of just one which is a bit ugly in my honest opinion.Benchmarks
Command:
cargo build -p wasmparser --no-default-features --features validate,features
Machine: Macbook M2 Pro
!simd
simd
debug
release
debug
release
ToDo's
wasm-tools
workspace.wasm-encoder
wasmprinter
wasm-mutate
simd
crate feature where possible.simd
definitions into a single file to speed-up conditional compilation gating.for_each_simd_operator
macro into its own separate file.BinaryReader::visit_0xfd_operator
into its own separate file.VisitSimdOperator
trait andSimdOperator
enum.macro_rules! for_each_simd_operator
enum SimdOperator
enumtrait VisitSimdOperator
VisitOperator::simd_visitor
Remove some duplicate code around macro expansions if possible.