> From: Kumar, Venkataramanan <[email protected]>
> Sent: Monday, July 6, 2026 1:54 AM
> 
> > From: Haochen Jiang <[email protected]>
> > Sent: Thursday, July 2, 2026 12:19 PM
> > To: [email protected]
> > Cc: [email protected]; [email protected]; Sharma, Dipesh
> > <[email protected]>; Kumar, Venkataramanan
> > <[email protected]>
> > Subject: [PATCH 2/7] Add tmm as fake register
> >
> > Caution: This message originated from an External Source. Use proper
> caution
> > when opening attachments, clicking links, or responding.
> >
> >
> > In legacy AMX, we use inline assembly for intrins since we are not doing 
> > tile
> > register allocation. For ACE, we will try a different way.
> >
> > Although we are not doing tile register allocation for now since there is no
> > convenient way for register spill, which is a must for register allocation, 
> > we
> are
> > going to make it convenient for future implementation for potential register
> > allocation. Thus, we will introduce a fake tmm register.
> 
> I understand deferring full tile RA for now.  The tile data can be spilled via
> repeated TILEMOVROW/TILEMOVCOL extract to ZMM and stores to an
> aligned stack slot (reverse on reload), or via TILELOADD/TILESTORED on the
> AMX-TILE path.  Please mention in the commit message to avoid implying spill
> is fundamentally not possible.

The spill is exactly what you said. But I did not get what do you mean by
" avoid implying spill is fundamentally not possible ". Spill is doable but just
not convenient. Since we should never mis-use legacy AMX and ACE, the only
way to do the spill is using tilemovrow/tilemovcol for 16 times, which might
even cause spill on zmms.

If there is a strong request for RA, that is the way we could do but user still
need to be careful on register usage, which is the same as now for users to
do the register allocation on their own. The spill is too costly.

> > diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc index
> > e66958db7ac..9cdd0138104 100644
> > --- a/gcc/config/i386/i386.cc
> > +++ b/gcc/config/i386/i386.cc
> > @@ -177,6 +177,8 @@ enum reg_class const
> > regclass_map[FIRST_PSEUDO_REGISTER] =
> >    GENERAL_REGS, GENERAL_REGS, GENERAL_REGS, GENERAL_REGS,
> >    GENERAL_REGS, GENERAL_REGS, GENERAL_REGS, GENERAL_REGS,
> >    GENERAL_REGS, GENERAL_REGS, GENERAL_REGS, GENERAL_REGS,
> 
> Why is only one fake register although we have 8 tile registers ??
> 

Several reasons:
1. It is an easier implementation method to cooperate with using reg
number in intrin.
2. Under the current situation of ACE, we do not need to complicate the
user case. The user case it to split the matrix into several part, do outer
product simultaneously, then accumulate. So, all the tmms will be used
at the same time. No need to distinguish them at this phase for now.

> >  /* ADJUST_REG_ALLOC_ORDER is a macro which permits reg_alloc_order
> >     to be rearranged based on a particular function.  When using sse math,
> > @@ -2107,7 +2111,8 @@ do {                                                  
> >     \
> >   "xmm28", "xmm29", "xmm30", "xmm31",                                   \
> >  "k0", "k1", "k2", "k3", "k4", "k5", "k6", "k7",                       \
> >  "r16", "r17", "r18", "r19", "r20", "r21", "r22", "r23",               \
> > - "r24", "r25", "r26", "r27", "r28", "r29", "r30", "r31" }
> > + "r24", "r25", "r26", "r27", "r28", "r29", "r30", "r31",               \
>
> Can we add "tmm" here ??
>

It is never used so we did not add it. But I suppose the answer is yes for 
clearance.

Thx,
Haochen

Reply via email to