Add TOSA f64 type support for cast op
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
The TOSA specification doesn't support F64, so I think we should be careful in how we expand the data types in the dialect. Adding it has implications for TOSA consumers.
At a minimum, code should be added to the tosa-validate pass that warns backends that attempt to align with the TOSA specification that non-compliant data types are present. The pass exists, it should be simple to report errors if FP64 operands are detected for any profile, as fp64 doesn't exist in a profile.
I'd also recommend that we proceed more incrementally with fp64. Rather than changing Tosa_Float, which changes almost all of the operators, create a new type, which is Tosa_Float + fp64, and use that only where needed. So if we only need fp64 for the CAST operator, the new type only gets used there. This would allow consumers of TOSA dialect to understand where f64 is needed, and would help reason about how fp64 would get added to the specification.
If any consumers of TOSA dialect have thoughts on F64 support, whether they want to avoid it, or are already capable of consuming it, it would be good to hear, even outside of this specific review.
Can you add a simple check to TosaValidation::runOnOperation that goes into the existing for loop and checks for float64 type, and does a signalPassFailure there? You don't need to check profileType, as f64 isn't in the spec. This pass is for implementations to use to check against the spec, so dialect specific changes that aren't in the spec should be flagged when it is run.
I am not familiar with this part of the code, could you check if adding is correct? Or any way to check if I am adding it correctly?
if (getElementTypeOrSelf(operand).isF64()) { return signalPassFailure(); }