> On Jul 31, 2017, at 12:40 PM, Michael Meissner <meiss...@linux.vnet.ibm.com> > wrote: > > On Sun, Jul 30, 2017 at 09:00:58AM -0500, Bill Schmidt wrote: >>>> (define_insn "vsx_concat_<mode>" >>>> - [(set (match_operand:VSX_D 0 "gpc_reg_operand" "=<VSa>,we") >>>> + [(set (match_operand:VSX_D 0 "vsx_register_operand" "=wa,we") >>>> (vec_concat:VSX_D >>>> - (match_operand:<VS_scalar> 1 "gpc_reg_operand" "<VS_64reg>,b") >>>> - (match_operand:<VS_scalar> 2 "gpc_reg_operand" "<VS_64reg>,b")))] >>>> + (match_operand:<VS_scalar> 1 "gpc_reg_operand" "wa,b") >>>> + (match_operand:<VS_scalar> 2 "gpc_reg_operand" "wa,b")))] >>>> "VECTOR_MEM_VSX_P (<MODE>mode)" >>>> { >>>> if (which_alternative == 0) >>>> - return (BYTES_BIG_ENDIAN >>>> - ? "xxpermdi %x0,%x1,%x2,0" >>>> - : "xxpermdi %x0,%x2,%x1,0"); >>>> + return rs6000_emit_xxpermdi (operands, NULL_RTX, NULL_RTX); >>>> >>>> else if (which_alternative == 1) >>>> - return (BYTES_BIG_ENDIAN >>>> + return (VECTOR_ELT_ORDER_BIG >>>> ? "mtvsrdd %x0,%1,%2" >>>> : "mtvsrdd %x0,%2,%1"); >>> >>> This one could be >>> >>> { >>> if (!BYTES_BIG_ENDIAN) >> >> !VECTOR_ELT_ORDER_BIG (to accommodate -maltivec=be). (We have some general >> bitrot associated with -maltivec=be that needs to be addressed, or we need >> to give up on it altogether. Still of two minds about this.) >> >> Bill > > In this case, I believe I tested -maltivec=be, and BYTES_BIG_ENDIAN is correct > (I originally had it using VECTOR_ELT_ORDER_BIG and got failures). But I need > to look at it again.
Hi Mike, You misunderstand me, I think you had it right (you did move to VECTOR_ELT_ORDER_BIG here) but I just wanted to clarify that Segher's suggestion would also need to use VECTOR_ELT_ORDER_BIG. Thanks, Bill > > -- > Michael Meissner, IBM > IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA > email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797