This PR refactors fixed-to-integer pass. I made three major changes:
Removing the assumption of top-level function args being 64-bit.
Removing the assumption that function arguments are all memref types.
Removing the annotation process of fixed-point type info.
Housekeeping 🧹
Removed duplicate code in binary op lowering.
Removed repeated updateAffineLoad calls.
Simplified func type and call op updating functions.
New tests
Two new tests from #193 and #194 are added to test/Transforms/datatype/fixedpoint.mlir
Notes for future references
There was an annotation process where each fixed-point operation is tagged with attributes to record its fixed-point type info, such as width, frac, sign. This was necessary because we were converting the operations from top to bottom. For example, if I have:
By the time we visit the second operation, the first operation is already lowered to arith.addi, and %0 becomes i5, and we don't know the fixed point type info for %0 anymore, i.e., converting the defining operation result type "covers" its users.
The annotation process solves this issue by tagging the fixed-point type info as attributes to these operations.
A better way to do this is to just transform the fixed-point operations in a reversed order in each block.
void visitBlock(Block &block) {
for (auto it = block.rbegin(); it != block.rend(); ++it) {
Operation &op = *it;
visitOperation(op);
}
}
This way, each operation conversion only updates the operation result, i.e. we update user operations first, and the upstream "defining" operations are not affected.
Description
This PR refactors
fixed-to-integerpass. I made three major changes:Housekeeping 🧹
updateAffineLoadcalls.New tests
Two new tests from #193 and #194 are added to
test/Transforms/datatype/fixedpoint.mlirNotes for future references
There was an annotation process where each fixed-point operation is tagged with attributes to record its fixed-point type info, such as width, frac, sign. This was necessary because we were converting the operations from top to bottom. For example, if I have:
By the time we visit the second operation, the first operation is already lowered to
arith.addi, and%0becomesi5, and we don't know the fixed point type info for%0anymore, i.e., converting the defining operation result type "covers" its users. The annotation process solves this issue by tagging the fixed-point type info as attributes to these operations.A better way to do this is to just transform the fixed-point operations in a reversed order in each block.
This way, each operation conversion only updates the operation result, i.e. we update user operations first, and the upstream "defining" operations are not affected.