Re: [PATCH V2] rs6000: Don't allow immediate value in the vsx_splat pattern [PR113950]

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

On 2/27/24 6:40 AM, Segher Boessenkool wrote:
> On Tue, Feb 27, 2024 at 02:02:38AM +0530, jeevitha wrote:
>> There is no immediate value splatting instruction in Power. Currently, those
>> values need to be stored in a register or memory. To address this issue, I
>> have updated the predicate for the second operand in vsx_splat to
>> splat_input_operand and corrected the assignment of op1 to operands[1].
>> These changes ensure that operand1 is stored in a register.
> 
> input_operand allows a lot of things that splat_input_operand does not,
> not just immediate operands.  NAK.
> 
> (For example, *all* memory is okay for input_operand, always).
> 
> I'm not saying we do not want to restrict these things, but a commit
> that doesn't discuss this at all is not okay.  Sorry.

So it seems you're not NAKing the use of splat_input_operand, but
just that it needs more explanation in the git log entry, correct?

Yes, input_operand accepts a lot more things than splat_input_operand
does, but the multiple define_insns this define_expand feeds, uses
gpc_reg_operand, memory_operand and splat_input_operand for their
operands[1] operand (splat_input_operand accepts reg and mem too),
so it seems to match better what the patterns will be accepting and
I always thought that using predicates that more accurately reflect
what the define_insns expect/accept lead to better code gen.

Mike, was it just an oversight to not use splat_input_operand for the
vsx_splat_<mode> expander or was input_operand a conscious decision?

If input_operand was used purposely, then we can just fall back to
the s/op1/operands[1]/ change which we already know fixes the bug.


Peter