On Thu, Jul 16, 2026 at 08:59:06AM +0530, Surya Kumari Jangala wrote:
> The Dense Math Facility, which may be present in a future processor,
> extends the Power architecture's computational capabilities by providing
> eight dedicated registers (dmr0-dmr7) that can efficiently handle large
> matrix operations. These registers will also be used in cryptographic
> operations.
> There are no operations to load/store Dense Math registers from/to
> memory. For loading from memory, the 1024 bit value is first loaded into
> 8 VSX registers which are then copied into a DMR register. Similarly,
> to store the contents of a DMR register into memory, the the contents
> of the DMR are copied to 8 VSX registers which are then loaded into
> memory.
> The DMR registers are treated as caller-saved.
>
> Key Features:
>
> 1. Register Infrastructure:
> - Adds 8 new DMR registers (dmr0-dmr7), numbered 111-118
> - Each register is 1024 bits (128 bytes) in size
> - Registers are call-used (caller-saved) following ABI conventions
> - Increases total pseudo registers from 111 to 119
>
> 2. Data Type Support:
> - TDOmode: New 1024-bit mode specifically for DMR operations
> - XOmode: Extended to support both MMA accumulators (in FPRs) and
> DMR registers, providing flexibility in register allocation
> - Both modes support DMR registers when TARGET_DMF is enabled
> - TDOmode and XOmode excluded from register tying to prevent
> incorrect cross-class allocation
>
> 3. Register Allocation:
> - Integrated DMR_REGS into the register class hierarchy
> - Added to register pressure classes for optimal allocation
> - Implements proper register allocation ordering
> - DMR registers can be allocated for XOmode and TDOmode values
>
> 4. Addressing and Memory Operations:
> - Supports offset addressing mode for TDOmode values
> - Implements secondary reload mechanisms for DMR ↔ VSX transfers
> - New rs6000_dmr_register_move_cost helper computes move costs
> between a DMR register and any register class via VSX:
> XOmode costs 2, TDOmode costs 4, other modes scale by nregs
> - Ensures proper alignment requirements (vector alignment)
> - rs6000_register_move_cost and rs6000_memory_move_cost extended
> to handle DMR_REGS as source or destination
>
> 5. Register Moves and Transfers:
> - Enables simple moves between DMR and VSX registers
>
> 6. Debugging and Toolchain Support:
> - Assigns debugger register numbers 112-119 for DMR registers
I would prefer you reformulate the patch and break it into separate
parts, and maybe combine later patches.
In particular, I feel strongly that each patch in sequence should be
able to stand alone and not cause issues if you use it in any case,
rather than waiting for a future patch to fill in the missing details.
The issue is if something needs revising in a later patch, if you have
installed the first set of patches, you have a broken tree.
I tried your patches, with the following code:
#ifndef TYPE
#define TYPE __vector_quad
#endif
#ifdef USE_VSX
#define CONSTRAINT "wa"
#else
#define CONSTRAINT "wD"
#endif
void copy (TYPE *p, TYPE *q)
{
*p = *q;
}
void do_asm (TYPE *p, TYPE *q)
{
TYPE x = *p;
__asm__(" # %A0" : "+" CONSTRAINT (x));
*q = x;
}
and I get reload errors.
In particular, I think we should have valid move insns for any
constraint that is legal. I also think combining __dmr1024 in with the
basic patch to add 512-bit dense math adds unnecessary complications.
The basic order that I think should be used is:
1: Add the wD constraint that only matches FPR registers divisible by 4
and accumulator_operand.
2: Change mma.md to use the wA constraint and accumulator_operand for
most of the patterns.
3: Add dense math registers for 512-bit registers, including movoo
support. Also, add the zero support needed. Make wD and
accumulator_operand deal with dense registers.
4: Add dense math registers for 1,024-bit registers, and add the
__dmr1024 type. Be sure to add the reload handler support.
Sorry to come down like this, but I do feel strongly that any one patch
should not need a later patch before it doesn't cause errors.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: [email protected]
