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. >