Re: [PATCH] middle-end: Skip initialization of opaque type register variables [PR103127]

[Qing Zhao <qing.zhao@oracle.com>]

> On Nov 30, 2021, at 9:14 AM, Peter Bergner <bergner@linux.ibm.com> wrote:
> 
> On 11/30/21 2:37 AM, Richard Biener wrote:
>> On Mon, Nov 29, 2021 at 11:56 PM Qing Zhao <qing.zhao@oracle.com> wrote:
>> I think that's inconsistent indeed.  Peter, what are "opaque"
>> registers?  rs6000-modes.def suggests
>> that there's __vector_pair and __vector_quad, what's the GIMPLE types
>> for those?  It seems they
>> are either SSA names or expanded to pseudo registers but there's no
>> constants for them.
> 
> The __vector_pair and __vector_quad types are target specific types
> for use with our Matrix-Math-Assist (MMA) unit and they are only
> usable with our associated MMA built-in functions.  What they hold
> is really dependent on which MMA built-ins you use on them.
> You can think of them a generic (and large) vector type where the
> subtype is undefined...or defined by which built-in function you
> happen to be using.
> 
> We do not have any constants defined for them.  How we initialize them
> is either by loading values from memory into them or by zeroing them
> out using the xxsetaccz instruction (only for __vector_quads).

So, looks like that the variable with OPAQUE_TYPE cannot be all explicitly initialized even at source code level. 

The only way to initialize such variable (only __vector_quad, not for __vector_pairs) at source code level is through call to __builtin_mma_xxsetaccz as:

void
foo (__vector_quad *dst)
{
  __vector_quad acc;
  __builtin_mma_xxsetaccz(&acc);
  *dst = acc;
}

Is this the correct understanding?

Is there way to initialize such variable to other values than zero at source code level?

Qing

> 
> 
> 
> 
>> Can they be initialized?  I see they can be copied at least.
> 
> __vector_quads can be zero initialized using the __builtin_mma_xxsetaccz()
> built-in function.  We don't have a method (or use case) for zero initializing
> __vector_pairs.


> 
> 
> 
>> If such "things" cannot be initialized they should indeed be exempt
>> from auto-init.  The
>> documentation suggests that they act as bit-bucked but even bit-buckets should
>> be initializable, thus why exactly does CONST0_RTX not exist for them?
> 
> We used to have CONST0_RTX defined (but nothing else), but we had problems
> with the compiler CSEing the initialization for multiple __vector_quads and
> then copying the values around.  We'd end up with one xxsetaccz instruction
> and copies out of that accumulator register into the other accumulator
> registers.  Copies are VERY expensive, while xxsetaccz's are cheap, so we
> don't want that.  That said, I think a fix I put in to disable fwprop on
> these types may have been the culprit for that problem, so maybe we could
> add the CONST0_RTX back?  I'd have to verify that.  If so, then we'd at least
> be able to support -ftrivial-auto-var-init=zero.  The =pattern version
> would be more problematical...unless the value for pattern was loaded from
> memory.
> 
> Peter
> 
>