This is an archive of the discontinued LLVM Phabricator instance.

[mlir][spirv] Initial support for 64 bit index type and builtins
ClosedPublic

Authored by Hardcode84 on Aug 22 2021, 7:06 AM.

Diff Detail

Event Timeline

Hardcode84 created this revision.Aug 22 2021, 7:06 AM
Hardcode84 requested review of this revision.Aug 22 2021, 7:06 AM
Hardcode84 retitled this revision from [mlir][spirv] Initial suuport for 64 bit index type and builtins to [mlir][spirv] Initial support for 64 bit index type and builtins.Aug 22 2021, 7:07 AM

fix gcc build

fix gcc build

tschuett added inline comments.
mlir/include/mlir/Dialect/SPIRV/Transforms/SPIRVConversion.h
59

Could this be driven by a data-layout on the gpu module?

Could this be driven by a data-layout on the gpu module?

Indeed. I'd like to adopt DataLayout (https://mlir.llvm.org/docs/DataLayout/) but haven't been able to find time for it. If @Hardcode84 you are interested, that'd be a very welcome contribution! But don't want to require refactoring the whole world to introduce a new functionality. :) So I'm fine of landing this to enable your use case for now too. Just a couple of nits.

mlir/include/mlir/Dialect/SPIRV/Transforms/SPIRVConversion.h
59

Nit: move these two booleans together? It helps packing a bit.

59

/// Use 64-bit integers to convert index types.

84

Is there a need to expose this as a public API?

140

Can we still leave the builder as the last parameter for all these functions?

Also here it's a utility function that has nothing to do with index. Just name the parameter as integerType?

142–143

32-bit needs to be changed here.

148–149

Same here: integerType.

mlir/lib/Dialect/SPIRV/Transforms/SPIRVConversion.cpp
788

We can get the index type from the typeConverter passed in?

antiagainst requested changes to this revision.Aug 23 2021, 8:52 AM
This revision now requires changes to proceed.Aug 23 2021, 8:52 AM

review comments

Hardcode84 marked 8 inline comments as done.Aug 23 2021, 12:22 PM

Basing this on the DataLayout is relatively lightweight. Take a look at how this is done in the LLVM lowering. Unless you had something more in mind.

Basing this on the DataLayout is relatively lightweight. Take a look at how this is done in the LLVM lowering. Unless you had something more in mind.

Yup. I'd prefer to do the switch for all, including the existing boolNumBits/etc. and how bitwidths for SPIR-V types are queried. Don't really like to be in a hybrid state where some datalayout configurations are coming from the IR while some are not. That can be quite confusing and error prone.

antiagainst accepted this revision.Aug 26 2021, 1:30 PM
This revision is now accepted and ready to land.Aug 26 2021, 1:30 PM