[PATCH] D135202: [IR] Add a target extension type to LLVM.

Craig Topper via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jan 10 20:03:47 PST 2023


craig.topper added a comment.

In D135202#4042268 <https://reviews.llvm.org/D135202#4042268>, @pengfei wrote:

> In D135202#4040194 <https://reviews.llvm.org/D135202#4040194>, @jcranmer-intel wrote:
>
>> In D135202#4038774 <https://reviews.llvm.org/D135202#4038774>, @zixuan-wu wrote:
>>
>>> I'd like to enable the backend infra and propose draft later. To better demonstrate and enable backend target-independent code completely, I'd like to demonstrate with x86_amx that changing x86_amx type to target extension type and make all test passed, if nobody objects.  @jcranmer-intel @LuoYuanke @craig.topper @pengfei
>>
>> I have no objections to this; indeed, my original proposal for target extension types included `x86_mmx` and `x86_amx` as types that could be implemented as target extension types. However, I'm not involved with the x86 backend, so I must defer to the proper codeowners there as to whether or not to do this.
>
> I think it's more appropriate to start with `x86_fp80` and `x86_mmx`. I'd expect there will be a more general matrix representation for the AMX type, e.g., TLX <https://discourse.llvm.org/t/rfc-proposal-for-tlx-tensor-llvm-extensions/59261>, <8x8xi8> <https://discourse.llvm.org/t/intel-amx-vector-dialect/2984> etc. rather than limit it to target extension type, though I'm not against to do prototype for it.

Aren't both x86_fp80 and x86_mmx recognized by InstCombine? They aren't truly opaque.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135202



More information about the llvm-commits mailing list