Re: [PATCH V3] rs6000: Don't ICE when compiling the __builtin_vsx_splat_2di built-in [PR113950]

[jeevitha <jeevitha@linux.ibm.com>]

Hi,

On 18/03/24 7:00 am, Kewen.Lin wrote:

>> The bogus vsx_splat_<mode> code goes all the way back to GCC 8, so we
>> should backport this fix.  Segher and Ke Wen, can we get an approval
>> to backport this to all the open release branches (GCC 13, 12, 11)?
>> Thanks.
> 
> Sure, okay for backporting this to all active branches, thanks!
> 

I need clarification regarding the backporting of PR113950 to GCC 12.

We encountered an issue while resolving merge conflicts in GCC 12. The 
problem lies in extra deletions in the diff due to cherry-picking. Now,
we're unsure about the best approach for handling the backport.

To provide context, I have included the relevant diff snippet below,

diff --cc gcc/config/rs6000/vsx.md
index c45794fb9ed,f135fa079bd..00000000000
--- a/gcc/config/rs6000/vsx.md
+++ b/gcc/config/rs6000/vsx.md
@@@ -4562,8 -4666,8 +4562,8 @@@
    rtx op1 = operands[1];
    if (MEM_P (op1))
      operands[1] = rs6000_force_indexed_or_indirect_mem (op1);
-   else if (!REG_P (op1))
-     op1 = force_reg (<VSX_D:VS_scalar>mode, op1);
+   else
 -    operands[1] = force_reg (<VSX_D:VEC_base>mode, op1);
++    operands[1] = force_reg (<VSX_D:VS_scalar>mode, op1);
  })

I'm seeking your advice on how to proceed with the backport. Do you
think the above change is acceptable, or should we also backport Segher's
commit e0e3ce634818b83965b87512938490df4d57f81d, which caused the conflict?.
There was no regression with both of these changes.

Jeevitha.