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). > 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
