This is an archive of the discontinued LLVM Phabricator instance.

[mlir][gpu] Add support for integer types in gpu.subgroup_mma ops
ClosedPublic

Authored by qedawkins on Feb 2 2023, 3:33 PM.

Details

Summary

The signedness is carried by !gpu.mma_matrix types to most closely
match the Cooperative Matrix specification which determines signedness
with the type (and sometimes the operation).

https://htmlpreview.github.io/?https://github.com/KhronosGroup/SPIRV-Registry/blob/master/extensions/NV/SPV_NV_cooperative_matrix.html

To handle the lowering from vector to gpu, ops such as arith.extsi are
pattern matched next to vector.transfer_read and vector.contract to
determine the signedness of the matrix type.

Diff Detail

Event Timeline

qedawkins created this revision.Feb 2 2023, 3:33 PM
qedawkins updated this revision to Diff 494997.Feb 5 2023, 9:26 PM

Adds pattern to infer signedness of mma type from signed extend

qedawkins updated this revision to Diff 495304.Feb 6 2023, 3:47 PM

Handle vector.transfer_read + vector.transpose fold and add tests

qedawkins published this revision for review.Feb 6 2023, 3:56 PM
qedawkins edited the summary of this revision. (Show Details)Feb 6 2023, 3:58 PM
ThomasRaoux accepted this revision.Feb 6 2023, 9:40 PM

What would happen if we run lowering to SPIRV or NVVM? We don't want to crash or miscompile.

mlir/lib/Conversion/VectorToGPU/VectorToGPU.cpp
202

do we need this?

This revision is now accepted and ready to land.Feb 6 2023, 9:40 PM

The lowering to SPIRV will just take the type from the mma_matrix type so as long as the types are set properly here then there should be no problems. The lowering otherwise doesn't look any different because the ops are the same. For the lowering to NVVM I realize I'm not as certain so I can either leave support for that to another PR or try and verify correctness now.

mlir/lib/Conversion/VectorToGPU/VectorToGPU.cpp
202

My thinking was that if there isn't a contraction op to match against, then we can't safely fuse the signed extend, but looking at this now there is no reason to actually have a check like this :P

qedawkins updated this revision to Diff 495376.Feb 6 2023, 9:56 PM

Remove check for empty uses

qedawkins updated this revision to Diff 495633.Feb 7 2023, 1:30 PM

Add support for int8 types in lowering to nvvm and rebase

@ThomasRaoux I added changes to the GPUToNVVM lowering to support integer types. Would it be better to move those changes to a separate revision?

ThomasRaoux accepted this revision.Feb 7 2023, 2:15 PM

Thanks for also adding lowering to nvvm!

@ThomasRaoux I added changes to the GPUToNVVM lowering to support integer types. Would it be better to move those changes to a separate revision?

I think it is fine but if you want to break it up a better way to slice it is to first add the op change + lowering then add the vector to mma in a second patch