Fix for Type Check in Quantized CPU op_dequantize #13174
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
When quantizing a model (without delegating to a specific backend), an exported model relies on the operator library in
kernels/quantized/cpu/
. Specifically, the essential operation ofop_dequantize
is performing:out = (in - offset) * scale
where the offset is an integer type. While initially, this offset is assumed to be an
uint64_t
(see here), when it is used to perform the operation above, it is cast down to auint32_t
(see here). It seems an implicit assumption is that the quantization offset is auint32_t
value, and theuint64_t
declaration is simply safeguarding for future proofing. In any event, the type check for the offset should allow the offset to be eitheruint32_t
or uint64_t`. This PR allows for that change.Test plan
Tested with mobilenet V2 on Arm backend. Quantized model runner initially crashed do to this check only allowing the offset to be
uint64_t
. When examining the values, none were larger thanUINT32_MAX
, so it should be safe to permit the offset to haveuint32_t
values. When this change was made, the mobilenet V2 runner was able to complete.