[aievec] Move trunc/ext to common lowering #1437
Conversation
jsetoain
force-pushed
the
move-ext-to-common-lowering
branch
from
8cc422e
to
29f01d2
Compare
|
|
||
| if (auto srsOp = dyn_cast<aievec::SRSOp>(op)) { | ||
| auto srsOpSrcOp = srsOp.getSource().getDefiningOp(); | ||
| if (isa<aievec::UPSOp>(srsOpSrcOp) || isa<aievec::CastOp>(srsOpSrcOp)) |
There was a problem hiding this comment.
Suppose that we have UPS from int8 => int32 followed by SRS from int32 => int16.
Would it be OK to return true in this case?
There was a problem hiding this comment.
I don't think we should because that's not a narrowing operation (int8 -> int16), but in this particular case it's looking for an SRS followed by either a UPS or a aievec.cast, which are the two possible conversion for trunc ops, depending on the operand types.
| // 2) Move from accumulator: aievec.srs | ||
| auto srsSource = srsOp.getSource(); | ||
| if (srsSource) | ||
| if (auto upsOp = srsSource.getDefiningOp<aievec::UPSOp>()) |
There was a problem hiding this comment.
Suppose that we have UPS from int16 => int32 followed by SRS from int32 to int8.
IMO, we should return sct::optional{} in this case.
There was a problem hiding this comment.
Indeed, that would be the thing to do since that's a narrowing operation, not a widening one. But we're not looking for UPS -> SRS sequences here, only SRS -> UPS.
| @@ -2757,6 +2799,98 @@ static void configureAIEVecCommonLegalizations(ConversionTarget &target, | |||
| target.addIllegalOp<vector::TransferReadOp>(); | |||
| } | |||
| target.addIllegalOp<vector::ExtractStridedSliceOp>(); | |||
|
|
|||
| // ****************************NEW**************************** | |||
There was a problem hiding this comment.
Line 2803 is probably unintended for this PR.
| @@ -2757,6 +2799,98 @@ static void configureAIEVecCommonLegalizations(ConversionTarget &target, | |||
| target.addIllegalOp<vector::TransferReadOp>(); | |||
| } | |||
| target.addIllegalOp<vector::ExtractStridedSliceOp>(); | |||
|
|
|||
| // ****************************NEW**************************** | |||
| target.addDynamicallyLegalOp<arith::ExtFOp>([](arith::ExtFOp extfOp) { | |||
There was a problem hiding this comment.
So basically this is saying that extf ops are legal, unless that they are from v16 bfloat16 to v16 f32.
There was a problem hiding this comment.
I honestly don't know what the logic is here, I haven't changed the semantics of what we do with these ops, just where it happens and what assumptions they're making about order and other patterns.
It'd probably be a good idea, at some point, to take a good look at all these casts (and movements between accumulator/regular register files) and see what needs to be done. There's probably a sensible way to not do any of this, and simplify the conversion.
There was a problem hiding this comment.
The test for this conversion pattern is missing from https://github.com/Xilinx/mlir-aie/tree/main/test/Conversion/VectorToAIEVec... It might be beneficial to create it this time.
| LowerVectorTransferReadToAIEUPD | ||
| >(patterns.getContext(), 128, 1024, 256, 1024); | ||
| patterns.add< | ||
| LowerVectorAddIOpToAIEVecAddElemOp |
There was a problem hiding this comment.
We can move below patterns to here as well.
LowerVectorSubIOpToAIEVecSubElemOp,
LowerVectorAddFOpToAIEVecAddElemOp,
LowerVectorSubFOpToAIEVecSubElemOp,
There was a problem hiding this comment.
Aren't those applicable for LLVMIR conversion as well?
jsetoain
force-pushed
the
move-ext-to-common-lowering
branch
2 times, most recently
from
5e40b95
to
efb0a87
Compare
Currently, trunc/ext ops get lowered in a separate pass with two simple patterns. This is mostly because other patterns check their users for these ops, which makes all the patterns involved dependent on each other and their order of application. This patch addresses this issue and moves these two last patterns together with all the other vector-to-aievec patterns.
jsetoain
force-pushed
the
move-ext-to-common-lowering
branch
from
efb0a87
to
1d4dd09
Compare
Currently, trunc/ext ops get lowered in a separate pass with two simple patterns. This is mostly because other patterns check their users for these ops, which makes all the patterns involved dependent on each other and their order of application.
This patch addresses this issue and moves these two last patterns together with all the other vector-to-aievec patterns.