[PATCH] D78974: [mlir][StandardToSPIRV] Emulate bitwidths not supported for load op.

[Han-Chung Wang via Phabricator via llvm-commits]

hanchung added a comment.

In D78974#2010386 <https://reviews.llvm.org/D78974#2010386>, @antiagainst wrote:

> In D78974#2009336 <https://reviews.llvm.org/D78974#2009336>, @mehdi_amini wrote:
>
> > Isn't this the kind of legalization that can be made on the std dialect itself as a pre-pass before the conversion to SPIRV? That would make all this logic reusable.
>
>
> Good question! But whether to do a specific type conversion is determined by the SPIR-V target environment and it can be quite nuanced. For example, if we only have `StorageBuffer16Acesss` capability then `memref<i16, 0>` will be fine but `memref<i8,0>`/`memref<i16, 4>`/etc. needs to be adjusted. There are many other similar capabilities like `UniformAndStorageBuffer16BitAccess`, `*8BitAccess`, `{Int|Float}{8|16|64}`, etc. This kind of information is only available when converting to SPIR-V and hide behind `SPIRVTypeConverter`. If this is to be implemented as a pre-pass operating on standard types, it's not quite clear to me how to solve the phase-ordering issue and rope the configuration there.
>  But regarding code reuse, I guess we might be able to extract some of the index adjusting logic out and change them to templated ones so one can also plug in std and other dialect ops to reuse.


Yes, as Lei said, the information of available integer width is hidden in SPIRVTypeConverter. I think some of code reuse could be like having a method `loadAndCast` where it would rewrite a std load to loading a `elementBits` element and applying a shift and an and mask. It'd be great if there are other targets need this, so we can think more about how to reuse it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D78974/new/

https://reviews.llvm.org/D78974