https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127264
Hongtao Liu <liuhongt at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |liuhongt at gcc dot gnu.org
--- Comment #13 from Hongtao Liu <liuhongt at gcc dot gnu.org> ---
>
> Yes, but the above representation pretends that there is just one tmm
> register and that it sets it to something. So, say if you set one %tmm1 to
> something and then tilezero on %tmm0, then RTL DCE could optimize the first
> store away.
> Either you need 8 tmm registers in RTL too, and (set (reg:V256SI
> TMM_FIRST_REGNUM + 1) (V256SI zero)), or, if all the tmm regs are
> (incorrectly) represented by a single TMM_REGNUM, I think safer
> representation would be (set (reg:BLK TMM_REGNUM) (unspec_volatile:BLK
> [(reg:BLK TMM_REGNUM) (match_operand:QI 0 "const_0_to_7_operand")]
> UNSPECV_TILEZERO)). You have some large set of registers and you change
> something in it.
Yes, since we don't support tile register allocation yet, we took the simpler
route of mapping all 8 tile registers to a single unified TMM_REGNUM instead of
defining them individually. This does introduce extra dependencies, but since
users are mostly writing GEMM kernels by hand anyway, it shouldn't be a big
issue in practice.
