> On Nov 30, 2021, at 9:14 AM, Peter Bergner <berg...@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.z...@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
>
>
