Re: [PATCH v2] rs6000: Prefer assigning the MMA vector operands to altivec registers [PR105556]

[Peter Bergner <bergner@linux.ibm.com>]

On 5/17/22 6:41 PM, Segher Boessenkool wrote:
> On Mon, May 16, 2022 at 05:31:31PM -0500, Peter Bergner wrote:
>>  (define_insn "mma_<vv>"
>> -  [(set (match_operand:XO 0 "fpr_reg_operand" "=&d")
>> -	(unspec:XO [(match_operand:V16QI 1 "vsx_register_operand" "wa")
>> -		    (match_operand:V16QI 2 "vsx_register_operand" "wa")]
>> +  [(set (match_operand:XO 0 "fpr_reg_operand" "=&d,&d")
>> +	(unspec:XO [(match_operand:V16QI 1 "vsx_register_operand" "v,?wa")
>> +		    (match_operand:V16QI 2 "vsx_register_operand" "v,?wa")]
> 
> You now have two "?" on alternative 1, instead of just one.  This is the
> same as if you had had
>   [(set (match_operand:XO 0 "fpr_reg_operand" "=&d,&d")
> 	(unspec:XO [(match_operand:V16QI 1 "vsx_register_operand" "v,??wa")
> 		    (match_operand:V16QI 2 "vsx_register_operand" "v,wa")]
> The "?" are per alternative, not really per operand.  It won't change
> much here of course, just penalise more than you perhaps expected.

Ak, ok.  I think giving an extra penalty is fine here, since we really
really want to use altivec regs here, so I went with the patch as is.
Pushed.

I'll wait a few days before backporting to GCC 12.  As for GCC 11 & 10,
I'll wait until someone actually has a test case that shows the same
problem.  I suspect a patch went into GCC 12 that changed the costs
slightly and that's why we don't see the problem on the older branches.
Thanks!

Peter