On Mon, Jul 6, 2026 at 5:32 AM Jiang, Haochen <[email protected]> wrote:
>
> > 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.
ISTR early-ra was introduced for a similar class of problems.
Richard.
> > > 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
