LuoYuanke added a comment. > 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)
Thank you for the suggestion. So here is my plan. 1. specify x86_amx in LangRef. 2. Add llvm.x86.tile.cast intrinsic. 3. Optimize some of llvm.x86.tile.cast code as bitcast does, and transform llvm.x86.tile.cast to amx intrinsic if it can't be eliminated. 4. After the above 3 items are finished, replace bitcast with llvm.x86.tile.cast in front-end when generate IR for amx builtin. 5. After some time for stabilization, remove bitcast transform code from LLVM. 6. After all of the llvm.x86.tile.cast work is finished, let's discuss about opaque type. Does that looks good to you? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D99152/new/ https://reviews.llvm.org/D99152 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
