-
Notifications
You must be signed in to change notification settings - Fork 59
Scaffolding to get started with SIMD on the Vector API #611
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
Conversation
|
This looks cool! I hope to have time to review this weekend. |
| } | ||
| } | ||
|
|
||
| private static void V128_NOT(MStack stack, Instance instance, Machine.Operands operands) { |
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.
for visibility to reviewers, this is:
- the demonstration that everything fits together
- how I'm envisioning the opcodes to be implemented
the other opcodes are just implementing fallbacks.
| private static Map<OpCode, Machine.OpImpl> additionalOpcodes; | ||
|
|
||
| static { | ||
| // TODO: discuss - either we use reflection or we need to restructure the project modules |
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.
An alternative approach would be to fully duplicate the runtime-tests module, the downside is that needs a bit of fiddling with profiles in Maven.
|
self-reminder: follow up task to remove this: https://github.com/dylibso/chicory/blob/main/wasm/src/test/resources/wasm/simd_load.0.wasm |
| </plugins> | ||
| </build> | ||
|
|
||
| <profiles> |
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.
How does this work in the IDE?
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'll double-check while rebasing 👍
|
|
||
| long[] call(int funcId, long[] args) throws ChicoryException; | ||
|
|
||
| Map<OpCode, OpImpl> additionalOpCodes(); |
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.
All of these changes are specific to the interpreter and don't make sense for AOT.
What if we take a different approach and have a protected method in InterpreterMachine that eval() calls in the default case for the opcode switch? Then you can have SimdMachine which subclasses InterpreterMachine and we won't need to change this interface.
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.
All of these changes are specific to the interpreter and don't make sense for AOT.
I haven't thought much about the compatibility with AOT indeed, I think I imagined invoking those as callHost or similar.
But I like the suggestion regarding eval, I'd go for it!
|
superseded by #652 |
This is one possible setup to start implementing SIMD with the Vector API.
There are a few tricks to make it working (project setup, a sprinkle of reflection etc.) I'm happy to turn this around when a different approach is proposed 🙂