[PATCH] D99152: [AMX] Prototype for vector and amx bitcast.

Florian Hahn via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Mar 31 01:20:25 PDT 2021


fhahn added a comment.

In D99152#2655880 <https://reviews.llvm.org/D99152#2655880>, @LuoYuanke wrote:

>> Whether to further optimizations are correct is a different problem, but we need a specification for the builtins, intrinsics and the type before going any further in that direction.
>>
>> I think you need to set the input to `LLVM IR`: https://gcc.godbolt.org/z/WexMjsas9
>>
>> You should be able to use opaque types with overloaded intrinsics. I don't think you define an intrinsic to take a specific opaque type (because it's not known up front).
>
> The opaque type (https://llvm.org/docs/LangRef.html#opaque-structure-types) is pretty new to me. I didn't find any example for the opaque type in builtins or intrinsics. I am appreciated if you would write an example code (maybe tilezero) for the builtins, intrinsics and the type, so that I can understand it well. If we use <256 x i32> in builtins and use x86_amx in intrinsics, and have an specific intrinsics to covert x86_amx to flat vector <256 x i32>, I am able to do it by myself.

Unfortunately this is not possible to use an opaque type with the AMX intrinsics at the moment, because of the way they are define. It is possible to use opaque types with intrinsics in general though, e.g. see https://llvm.godbolt.org/z/Ezhf6535c

My point is, you should be able to adjust the definitions of the AMX intrinsics and then just replace all occurrences of `x86_amx` in your examples with a opaque type you define in the module. But as I said initially, you don't need to do everything at once (and you probably shouldn't). I'd start with addressing the bitcast issue and tackle the `x86_amx` type itself once that is done.

(And I am also not saying that it definitely needs to be removed, only that if it should be kept in the long run, it would be good to specify it in the LangRef and should have a good justification, especially if there are no instructions that do anything meaningful with values of the type other than take it as arguments and return values. Opaque types are a suggestion for an alternative that *may* be viable without a dedicated first-class type)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99152



More information about the llvm-commits mailing list