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

["Kewen.Lin" <linkw@linux.ibm.com>]

Hi,

on 2024/4/17 17:05, jeevitha wrote:
> 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?.

I prefer the former, which is the least modification, for release branches
let's introduce as few changes as possible, and the amendment on the conflict
is minor and straightforward.

BR,
Kewen

> There was no regression with both of these changes.
> 
> Jeevitha.
>