[PATCH] middle-end: Skip initialization of opaque type register variables [PR103127]
Tue Nov 30 15:14:38 GMT 2021
On 11/30/21 2:37 AM, Richard Biener wrote:
> On Mon, Nov 29, 2021 at 11:56 PM Qing Zhao <email@example.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).
> 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
> 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
More information about the Gcc-patches