Hi Segher,
Thanks for the comments.
on 2022/6/24 03:06, Segher Boessenkool wrote:
> Hi!
>
> On Wed, May 18, 2022 at 10:07:48PM +0800, Kewen.Lin wrote:
>> As PR103353 shows, we may want to continue to expand a MMA built-in
>> function like a normal function, even if we have already emitted
>> error messages about some missing required conditions. As shown in
>> that PR, without one explicit mov optab on OOmode provided, it would
>> call emit_move_insn recursively.
>
> First off: lxvp is a VSX insn, not an MMA insn. So please don't call it
> that -- this confusion is what presumably caused the problem here, so it
> would be good to root it out :-)
>
I guess the "it" in "don't call it call" is for "MMA built-in function"?
It comes from the current code:
; mma Needs special handling for MMA
; quad MMA instruction using a register quad as an input operand
; pair MMA instruction using a register pair as an input operand
v256 __builtin_vsx_lxvp (unsigned long, const v256 *);
LXVP nothing {mma}
void __builtin_vsx_stxvp (v256, unsigned long, const v256 *);
STXVP nothing {mma,pair}
...
>> + /* Opaque modes are only expected to be available when MMA is supported,
>
> Why do people expect that? It is completely wrong. The name "opaque"
> itself already says this is not just for MMA, but perhaps more
> importantly, it is a basic VSX insn, doesn't touch any MMA resources,
> and is useful in other contexts as well.
>
... The above statements are also based on current code, for now, the
related things like built-in functions, mov optab, hard_regno_ok etc.
for these two modes are guarded by TARGET_MMA.
I think I get your points here, you want to separate these opaque
modes from MMA since the underlying lxvp/stxvp are not MMA specific,
so those related things (bifs, mov optabs etc.) are not necessarily
guarded under MMA.
> So this needs some bigger surgery.
Yes, Peter may have more comments on this.
BR,
Kewen
