Signed-off-by: xin1.wang <xin1.wang@intel.com>
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
Spec does not show bitwidth limit. From https://github.com/KhronosGroup/SPIRV-Tools/blob/master/test/val/val_conversion_test.cpp#L372 can get a cast to convert s64 to f32; And std.SIToFPOp dose not has the limit too. May be same issues with other cast ops
ConvertSToF shall support operands with same bitwidth and different bitwidth. The check of component number shall be done by another way.
Why is this only for SToFP op? We should keep it consistent for the different converts. Also you need to add test(s).
Just to keep minimal changes as i need this op support now. Will check other castOp and add tests soon, thanks.
SPV_ConvertFToSOp, SPV_ConvertFToUOp, SPV_ConvertSToFOp, SPV_ConvertUToFOp can support same && different bit widths of their operand type and result type. As The type definition limits the type and ODS checks the shape, skip bit widths check for those CastOps are enough now.
mlir/lib/Dialect/SPIRV/SPIRVOps.cpp | ||
---|---|---|
310–312 ↗ | (On Diff #290640) | This seem to skip more than just the bitwidth check. I don't think we can skip the check that the shape are different. Why can't we just set requireSameBitWidth to false? |
mlir/lib/Dialect/SPIRV/SPIRVOps.cpp | ||
---|---|---|
310–312 ↗ | (On Diff #290640) | When we just set requireSameBitWidth to false, it will report error when the bit widths of operand and result type are same(The 344 line check this), all the codes below just get element type and check bit widths, and either request same or different, no other choice, so just ignore. For shape issue, the CastOp definition use SameOperandsAndResultShape trait to check this, no check here. |
mlir/lib/Dialect/SPIRV/SPIRVOps.cpp | ||
---|---|---|
310–312 ↗ | (On Diff #290640) | You're right, my bad. |
I don't have commit access as a new contributor,if everything is fine, can anyone help me push the changes? Really thanks.