You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is PR 4 in a series of N patches aimed at improving
"VectorEmulateNarrowType.cpp". This is mainly minor refactoring, no
major functional changes are made/added.
1. Update `alignedConversionPrecondition` (1):
This method didn't require the vector type for the "destination"
argument. The underlying element type is sufficient. The corresponding
argument has been renamed as `multiByteScalarTy` - this is meant as the
multi-byte emulated type (`i8`, `i16`, `i32`, etc).
2. Update `alignedConversionPrecondition` (2):
In #121298, we replaced `dstElemBitwidt` in this calculation:
```cpp
const int numSrcElemsPerDestElem = dstElemBitwidth / srcElemBitwidth;
```
with the hard-coded value of 8:
```cpp
const int numSrcElemsPerDestElem = 8 / srcElemBitwidth;
```
That was correct as for the patterns for which this hook was/is used:
* `RewriteAlignedSubByteIntExt`,
* `RewriteAlignedSubByteIntTrunc`.
The destination type (or, more precisely, the emulated type) was always
`i8`.
In this PR, I am switching back to a more generic approach - the
calculation should take into account the bit-width of the emulated type.
Note that at the call sites I am passing `i8` as the emulated type, so the
end-result is effectively identical. However, the intent is clearer, i.e.,
the underlying value is 8 because the emulated type happens to be `i8`
(as opposed using a magic number).
3. Update alignedConversionPrecondition (3):
The final check has been replaced with a new helper method,
`isSubByteVecFittable`. This new method is also re-used within the code
and hopefully will allow us more code re-use moving forward (to avoid
re-implementing the same condition).
4. Update alignedConversionPrecondition (4):
NEXT STEPS:
We need to clarify the meaning of "source" and "destination" types.
Currently the usage is ambiguous.
For example, for this `arith.extsi` Op, `vector<8xi2>` and
`vector<8xi32>` are the "source" and "destination" types, respectively:
```mlir
%0 = arith.extsi %arg0 : vector<8xi2> to vector<8xi32>
}
```
However, patterns like `RewriteAlignedSubByteIntExt` introduce
`vector.bitcast` Ops like this:
```mlir
%bitcast = vector.bitcast %arg0 : vector<8xi2> to vector<2xi8>
```
I've noticed that we tend to mix `vector<2xi8>` and `vector<8xi32>` as
the destination types and that should be clarified.
0 commit comments