search for: tileloaddv

...After instruction selection, the pseudo AMX instruction is > generated. The name of pseudo instructions have ‘P’ prefix. Now all > the AMX pseudo instruction take vtile as register class. Let’s assume > %13 is constant 3, %10 is constant 4 and %14 is variable. > > /  %1:vtile = *P*TILELOADDV %13:gr16, %10:gr16, %17:gr64, 1, > %18:gr64_nosp, 0, $noreg/ > > /  %2:vtile = *P*TILELOADDV %10:gr16, %14:gr16, %17:gr64, 1, > %18:gr64_nosp, 0, $noreg/ > > /  %3:vtile = *P*TILELOADDV %13:gr16, %14:gr16, %17:gr64, 1, > %18:gr64_nosp, 0, $noreg/ > > /%21:vtile = *P*TD...

...tion selection, the pseudo AMX instruction is > generated. The name of pseudo instructions have ‘P’ prefix. Now > all the AMX pseudo instruction take vtile as register class. Let’s > assume %13 is constant 3, %10 is constant 4 and %14 is variable. > > /  %1:vtile = *P*TILELOADDV %13:gr16, %10:gr16, %17:gr64, 1, > %18:gr64_nosp, 0, $noreg/ > > /  %2:vtile = *P*TILELOADDV %10:gr16, %14:gr16, %17:gr64, 1, > %18:gr64_nosp, 0, $noreg/ > > /  %3:vtile = *P*TILELOADDV %13:gr16, %14:gr16, %17:gr64, 1, > %18:gr64_nosp, 0, $noreg/ > >...

...e16x16). 1. After instruction selection, the pseudo AMX instruction is generated. The name of pseudo instructions have 'P' prefix. Now all the AMX pseudo instruction take vtile as register class. Let's assume %13 is constant 3, %10 is constant 4 and %14 is variable. %1:vtile = PTILELOADDV %13:gr16, %10:gr16, %17:gr64, 1, %18:gr64_nosp, 0, $noreg %2:vtile = PTILELOADDV %10:gr16, %14:gr16, %17:gr64, 1, %18:gr64_nosp, 0, $noreg %3:vtile = PTILELOADDV %13:gr16, %14:gr16, %17:gr64, 1, %18:gr64_nosp, 0, $noreg %21:vtile = PTDPBSSDV %13:gr16, %10:gr16, %14:gr16, %3:vtile(tied-def 0), %...

...e16x16). 1. After instruction selection, the pseudo AMX instruction is generated. The name of pseudo instructions have 'P' prefix. Now all the AMX pseudo instruction take vtile as register class. Let's assume %13 is constant 3, %10 is constant 4 and %14 is variable. %1:vtile = PTILELOADDV %13:gr16, %10:gr16, %17:gr64, 1, %18:gr64_nosp, 0, $noreg %2:vtile = PTILELOADDV %10:gr16, %14:gr16, %17:gr64, 1, %18:gr64_nosp, 0, $noreg %3:vtile = PTILELOADDV %13:gr16, %14:gr16, %17:gr64, 1, %18:gr64_nosp, 0, $noreg %21:vtile = PTDPBSSDV %13:gr16, %10:gr16, %14:gr16, %3:vtile(tied-def 0), %...

The width and height can be runtime values that we would just copy into 64 byte configuration block we pass to ldtilecfg. So the code doesn't need to be multiversioned. The user code would also use those values to update pointers in the loops they write using the tiles. If we can't determine that two tiles were defined with the same width and height we need to assume the shape is different