diff options
| author | James Newling <james.newling@gmail.com> | 2025-05-01 15:50:55 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-05-01 15:50:55 -0700 |
| commit | 1a44f38d2af8724e9819f03d4b76a50615217a8d (patch) | |
| tree | 670c93ea3ea0e5fc312ec2239b61dd76181fb548 /lldb/test/API/python_api | |
| parent | ed8d4fe0b1d8088bd1a4f99f77afe33f435ef668 (diff) | |
| download | llvm-1a44f38d2af8724e9819f03d4b76a50615217a8d.zip llvm-1a44f38d2af8724e9819f03d4b76a50615217a8d.tar.gz llvm-1a44f38d2af8724e9819f03d4b76a50615217a8d.tar.bz2 | |
[mlir][vector] Canonicalize/fold 'order preserving' transposes (#135841)
Handles special case where transpose doesn't permute any non-1
dimensions (and so is effectively a shape_cast) and is adjacent to a
shape_cast that it can fold into. For example
```
%1 = vector.transpose %0, [1, 0, 3, 2] : vector<4x1x1x6xf32> to vector<1x4x6x1xf32>
```
can be folded into an adjacent shape_cast. An alternative to this PR
would be to canonicalize such transposes to shape_casts directly, but I
think it'll be difficult getting consensus that shape_cast is 'more
canonical' than transpose, so this PR compromises with the less
opinionated claim that
1) shape_cast is more canonical than shape_cast(transpose)
2) shape_cast is more canonical than transpose(shape_cast)
The pattern `ConvertIllegalShapeCastOpsToTransposes` that is specific to
transposes with scalable dimensions reverses the canonicalization added
here, so I've I've disabled this canonicalization for scalable vectors
Diffstat (limited to 'lldb/test/API/python_api')
0 files changed, 0 insertions, 0 deletions
