-
Notifications
You must be signed in to change notification settings - Fork 5.4k
[wasm][interp] Fix ConvertToInteger intrinsic on wasm #127220
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -14,6 +14,13 @@ void InterpConfigValues::Initialize(ICorJitHost* host) | |||||
| #define RELEASE_CONFIG_INTEGER(name, key, defaultValue) m_##name = host->getIntConfigValue(key, defaultValue); | ||||||
| #include "interpconfigvalues.h" | ||||||
|
|
||||||
| #ifdef TARGET_WASM | ||||||
| // WASM-TODO: update when R2R is enabled | ||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is replacing one bug with a different bug. I do not think we want to do this. We are actively working on enabling R2R, so the folks working on that will need to be reverting this change all the time. Also, this configuration is duplicated on the VM side. It is hard to reason about the behavior when the VM side and the interpter side do not agree about the mode that the interpreter is running in.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I was hoping to get some performance gain meanwhile, before we have the R2R intrinsics in place. What if I guard it by That would work better for folks working on R2R.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
The intrinsics are implemented in the interpreter for correctness only, any performance improvement is accidental. I doubt that you would see a measurable performance gain.
I am not sure what you mean.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't follow why we would need to tweak the interp mode. If we have an interpreter implementation for an intrinsic that is correct and fast, shouldn't we use it all the time, regardless of the interp mode ?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Some intrinsics do not have fully defined behavior. However, we do want to guarantee that the behavior is same within the process lifetime, so we either want to use interpreter implementation of the intrinsics all the time in given process; or R2R implementation of the intrinsics all the time in a given process, but we do not want to mix and match.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If that's the case, seems like it would mean that we need to avoid intrinsifying those methods in interpreter, given r2r code would be using that different behavior that we have no control over. So I would expect this PR to remove intrinsic support, to match JIT behavior, rather than add new one. Anyhow, I don't think we should care about InterpMode=3 performance since it won't be used anywhere. I still don't understand how changing it here makes any difference. Since on no-JIT platforms we already interpret everything that the runtime asks us to (so methods that weren't already found in r2r). |
||||||
| // Default to InterpMode 3 unless explicitly overridden via DOTNET_InterpMode. | ||||||
|
||||||
| // Default to InterpMode 3 unless explicitly overridden via DOTNET_InterpMode. | |
| // On WASM, treat InterpMode 0 as InterpMode 3. |
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 case now covers both ConvertToInteger and ConvertToIntegerNative, but the error text later in the block still says "ConvertToIntegerNative: source type is not floating point". Consider updating that diagnostic to mention both intrinsics (or use a generic "ConvertToInteger" message) so failures are not misleading.