-
Notifications
You must be signed in to change notification settings - Fork 739
add_int16_cast adds uint16 cast causing underflow of int16-compatible int32 value
#2626
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?
Conversation
|
Thanks for the pull request. The fix looks good to me. CI: https://gitlab.com/coremltools1/coremltools/-/pipelines/2189637393 |
|
@TobyRoseman the CI pipeline looks to be passing. Are you happy to get this merged? |
|
@kasper0406 - before I merge, can you please address my one comment. |
|
Sorry, I don't see any comments. Did you click "submit review"? |
My bad. I've done it now. Thanks. |
|
Cool, thanks! It's quite late here now, but I'll get it fixed over the weekend. |
|
Updated CI: https://gitlab.com/coremltools1/coremltools/-/pipelines/2202537993 If this passes, I will merge this pull request. |
The current
add_int16_castimplementation has a side-effect in theshould_cast_parametermethod. It updates thetarget_dtypemember when it is being called on different parameters. Thistarget_dtypevalue is then used in thetransform_opmethod, to add casts. The issue is that, in certain cases, thetarget_dtypedoes not get correctly reset between parameters, and unintended uint16 casts can occur!The added test case will fail with:
An easy fix would have been to reset the
target_dtypestate in every call toshould_cast_parameter.However, I believe this design is quite confusing, and likely to cause further issues, so I've gone ahead and refactored the code to make
should_cast_parameterreturn an optional with the parameter's target dtype instead of having a side effect.The
transform_function_signaturesmethod iterates the function inputs, and usesself.target_dtypeto modify the inputs. This function did not useshould_cast_parameterbefore as well, so depending on if it is called before/after the parameter conversion code, it may use a differentself.target_dtypebased on parameter ordering. In the new version, it will always use the default target_dtype. I am not sure what the correct behavior is here.