[V2] PowerPC vector pair support

This is version 2 of the patch to add functions to allow high performance
libraries to write their code so that they can do streaming math functions
using the Power10 load vector pair and store vector pair instructions.

This patch adds 2 functions to swap the even and odd elements.  This is from
feedback that I got from one person who has worked on high performance
libraries in the past that having this swap operation would help improve
complex multiply operations:

    *	vpair_f32_swap_odd_even
    *	vpair_f64_swap_odd_even

Can I check this updated patch into the trunk?  I have tested this on both big
endian and little endian systems with no regressions.  The new tests pass
including the execution tests when the test run is done on a power10 system.

Here were the original posts:

    *	https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664694.html
    *	https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664701.html

This patch adds a new include file (vector-pair.h) that adds support so that
users writing high performance libraries can change their code to allow the
generation of the vector pair load and store instructions on power10.

The intention is that if the library authors need to write special loops that
go over arrays that they could modify their code to use the functions provided
to change loops that can take advantage of the higher bandwidth for load vector
pair and store instructions.

This particular patch just adds a new include file (vector-pair.h) that
provides a bunch of functions that on a power10 system would use the vector
pair load operation, 2 floating point operations, and a vector pair store.  It
does not add any new types, modes, or built-in function.

I have additional patches that can add built-in functions that the functions in
vector-pair.h could utilize so that the compiler can optimize and combine
operations.  I may submit those patches in the future, but I would like to
provide this patch to allow the library writer to optimize their code.

I've measured the performance of these new functions on a power10.  For default
unrolling, the percentage of change for the 3 methods over the normal vector
loop method:

	116%	Vector-pair.h function, default unroll
	 93%	Vector pair split built-in & 2 vector stores, default unroll
	 86%	Vector pair split & combine built-ins, default unroll

Using explicit 2 way unrolling the numbers are:

	114%	Vector-pair.h function, unroll 2
	106%	Vector pair split built-in & 2 vector stores, unroll 2
	 98%	Vector pair split & combine built-ins, unroll 2

These new functions provided in vector-pair.h use the vector pair load/store
instructions, and don't generate extra vector moves.  Using the existing
vector pair disassemble and assemble built-ins generate extra vector moves
which can hinder performance.

If I compile the loop code for power9, there is a minor speed up for default
unrolling and more of an improvement using the framework provided in the
vector-pair.h for explicit unrolling by 2:

	101%	Vector-pair.h function, default unroll for power9
	107%	Vector-pair.h function, unroll 2 for power9

Of course this is a synthetic benchmark run on a quiet power10 system.  Results
would vary for real code on real systems.  However, I feel adding these
functions can allow the writers of high performance libraries to better
optimize their code.

As an example, if the library wants to code a simple fused multiply-add loop,
they might write the code as follows:

	#include <altivec.h>
	#include <math.h>
	#include <stddef.h>

	void
	fma_vector (double * __restrict__ r,
		    const double * __restrict__ a,
		    const double * __restrict__ b,
		    size_t n)
	{
	  vector double * __restrict__ vr = (vector double * __restrict__)r;
	  const vector double * __restrict__ va = (const vector double * __restrict__)a;
	  const vector double * __restrict__ vb = (const vector double * __restrict__)b;
	  size_t num_elements = sizeof (vector double) / sizeof (double);
	  size_t nv = n / num_elements;
	  size_t i;

	  for (i = 0; i < nv; i++)
	    vr[i] = __builtin_vsx_xvmadddp (va[i], vb[i], vr[i]);

	  for (i = nv * num_elements; i < n; i++)
	    r[i] = fma (a[i], b[i], r[i]);
	}

The inner loop would look like:

	.L3:
		lxvx 0,3,9
		lxvx 12,4,9
		addi 10,9,16
		addi 2,2,-2
		lxvx 11,5,9
		xvmaddadp 0,12,11
		lxvx 12,4,10
		lxvx 11,5,10
		stxvx 0,3,9
		lxvx 0,3,10
		addi 9,9,32
		xvmaddadp 0,12,11
		stxvx 0,3,10
		bdnz .L3

Now if you code the loop to use __builtin_vsx_disassemble_pair to do a vector
pair load, but then do 2 vector stores:

	#include <altivec.h>
	#include <math.h>
	#include <stddef.h>

	void
	fma_mma_ld (double * __restrict__ r,
		    const double * __restrict__ a,
		    const double * __restrict__ b,
		    size_t n)
	{
	  __vector_pair * __restrict__ vp_r = (__vector_pair * __restrict__)r;
	  const __vector_pair * __restrict__ vp_a = (const __vector_pair * __restrict__)a;
	  const __vector_pair * __restrict__ vp_b = (const __vector_pair * __restrict__)b;
	  vector double * __restrict__ v_r = (vector double * __restrict__)r;
	  size_t num_elements = (sizeof (__vector_pair) / sizeof (double));
	  size_t n_vp = n / num_elements;
	  size_t i, j;
	  vector double a_hi_lo[2];
	  vector double b_hi_lo[2];
	  vector double r_hi_lo[2];
	  vector double result_hi, result_lo;

	  j = 0;
	  for (i = 0; i < n_vp; i++)
	    {
	      __builtin_vsx_disassemble_pair (&a_hi_lo[0], &vp_a[i]);
	      __builtin_vsx_disassemble_pair (&b_hi_lo[0], &vp_b[i]);
	      __builtin_vsx_disassemble_pair (&r_hi_lo[0], &vp_r[i]);

	      result_hi = __builtin_vsx_xvmadddp (a_hi_lo[0], b_hi_lo[0], r_hi_lo[0]);
	      result_lo = __builtin_vsx_xvmadddp (a_hi_lo[1], b_hi_lo[1], r_hi_lo[1]);

	      v_r[ j+0 ] = result_hi;
	      v_r[ j+1 ] = result_lo;
	      j += 2;
	    }

	  for (i = n_vp * num_elements; i < n; i++)
	    r[i] = fma (a[i], b[i], r[i]);
	}

And the inner loop would looke like:

	.L72:
		lxvpx 10,4,2
		lxvpx 0,5,2
		lxvpx 12,3,2
		xxlor 8,11,11
		xxlor 11,1,1
		xvmaddmdp 0,10,12
		xvmaddmdp 11,8,13
		stxvx 11,3,2
		stxvx 0,9,2
		addi 2,2,32
		bdnz .L72

I.e. it does 3 vector pair loads, but it adds 2 extra vector moves in the loop.
Also, normal unrolling does not unroll this loop.  But you can use #pragma GCC
unroll 2 to explicitly unroll the loop, and it would generate:

	.L97:
		lxvpx 6,3,2
		addi 9,2,32
		lxvpx 12,4,2
		lxvpx 4,5,2
		lxvpx 8,5,9
		lxvpx 10,3,9
		lxvpx 0,4,9
		xxlor 32,13,13
		xxlor 13,7,7
		xvmaddmdp 12,4,6
		xxlor 7,9,9
		xxlor 9,13,13
		xvmaddmdp 0,8,10
		xvmaddadp 9,5,32
		xvmaddadp 11,7,1
		stxvx 9,3,2
		stxvx 12,10,2
		addi 2,2,64
		stxvx 11,3,9
		stxvx 0,10,9
		bdnz .L97

I.e. it now adds 4 extra vector moves instead of 2,

If you try to do vector pair loads, split the vector pairs into separate
vectors, do the fma, and then combine the two vector resultss back into a
vector pair, the code might look like:

	#include <altivec.h>
	#include <math.h>
	#include <stddef.h>

	void
	fma_mma_ld_st (double * __restrict__ r,
		       const double * __restrict__ a,
		       const double * __restrict__ b,
		       size_t n)
	{
	  __vector_pair * __restrict__ vp_r = (__vector_pair * __restrict__)r;
	  const __vector_pair * __restrict__ vp_a = (const __vector_pair * __restrict__)a;
	  const __vector_pair * __restrict__ vp_b = (const __vector_pair * __restrict__)b;
	  size_t num_elements = (sizeof (__vector_pair) / sizeof (double));
	  size_t n_vp = n / num_elements;
	  size_t i;
	  union vec_alias {
	    vector double		 vd;
	    vector unsigned char	 vuc;
	  };
	  vector double a_hi_lo[2];
	  vector double b_hi_lo[2];
	  vector double r_hi_lo[2];
	  union vec_alias result_hi, result_lo;

	  for (i = 0; i < n_vp; i++)
	    {
	      __builtin_vsx_disassemble_pair (&a_hi_lo[0], &vp_a[i]);
	      __builtin_vsx_disassemble_pair (&b_hi_lo[0], &vp_b[i]);
	      __builtin_vsx_disassemble_pair (&r_hi_lo[0], &vp_r[i]);

	      result_hi.vd = __builtin_vsx_xvmadddp (a_hi_lo[0], b_hi_lo[0], r_hi_lo[0]);
	      result_lo.vd = __builtin_vsx_xvmadddp (a_hi_lo[1], b_hi_lo[1], r_hi_lo[1]);

	      __builtin_vsx_build_pair (&vp_r[i], result_hi.vuc, result_lo.vuc);
	    }

	  for (i = n_vp * num_elements; i < n; i++)
	    r[i] = fma (a[i], b[i], r[i]);
	}

The inner loop would look like:

	.L128:
		lxvpx 10,4,2
		lxvpx 0,5,2
		lxvpx 12,3,2
		xxlor 9,10,10
		xxlor 10,11,11
		xxlor 11,1,1
		xvmaddmdp 0,9,12
		xvmaddmdp 11,10,13
		xxlor 12,0,0
		xxlor 13,11,11
		stxvpx 12,3,2
		addi 2,2,32
		bdnz .L128

I.e. there are now 3 extra vector moves after the load vector pair instruction,
and 2 vector moves to combine the vector back into a vector pair.

If you use an explicit #pragma GCC unroll 2, the code generated would be:

	.L153:
		lxvpx 10,3,2
		addi 9,2,32
		lxvpx 6,4,2
		lxvpx 8,5,2
		lxvpx 12,5,9
		lxvpx 0,4,9
		xxlor 3,11,11
		xxlor 5,6,6
		xxlor 6,7,7
		xxlor 7,9,9
		xxlor 11,12,12
		xxlor 12,3,3
		xvmaddadp 10,5,8
		xxlor 9,13,13
		xvmaddadp 12,7,6
		xxlor 6,10,10
		xxlor 7,12,12
		stxvpx 6,3,2
		addi 2,2,64
		lxvpx 12,3,9
		xxlor 10,12,12
		xxlor 12,13,13
		xvmaddmdp 0,11,10
		xvmaddadp 12,9,1
		xxlor 10,0,0
		xxlor 11,12,12
		stxvpx 10,3,9
		bdnz .L153

Finally, if you recode the loop to use the vpair_f64_fma function in this
patch, the code would look like:

	#include <altivec.h>
	#include <math.h>
	#include <vector-pair.h>
	#include <stddef.h>

	void
	fma_vpair (double * __restrict__ r,
		   const double * __restrict__ a,
		   const double * __restrict__ b,
		   size_t n)
	{
	  vector_pair_f64_t * __restrict__ vp_r = (vector_pair_f64_t * __restrict__)r;
	  const vector_pair_f64_t * __restrict__ vp_a = (const vector_pair_f64_t * __restrict__)a;
	  const vector_pair_f64_t * __restrict__ vp_b = (const vector_pair_f64_t * __restrict__)b;
	  size_t num_elements = (sizeof (vector_pair_f64_t) / sizeof (double));
	  size_t n_vp = n / num_elements;
	  size_t i;

	  for (i = 0; i < n_vp; i++)
	    vpair_f64_fma (&vp_r[i], &vp_a[i], &vp_b[i], &vp_r[i]);

	  for (i = n_vp * num_elements; i < n; i++)
	    r[i] = fma (a[i], b[i], r[i]);
	}

The inner loop would generate:

	.L184:
		addi 9,2,32
		lxvpx 0,3,2
		lxvpx 8,4,2
		lxvpx 6,5,2
		lxvpx 12,4,9
		lxvpx 10,5,9
	#APP
	 # 437 "./include/vector-pair.h" 1
		xvmaddadp 0,8,6
		xvmaddadp 0+1,8+1,6+1
	 # 0 "" 2
	#NO_APP
		stxvpx 0,3,2
		addi 2,2,64
		lxvpx 0,3,9
	#APP
	 # 437 "./include/vector-pair.h" 1
		xvmaddadp 0,12,10
		xvmaddadp 0+1,12+1,10+1
	 # 0 "" 2
	#NO_APP
		stxvpx 0,3,9
		bdnz .L184

I.e. there are no extra vector moves in this loop, and normal unrolling does
duplicate this loop.

The vector-pair.h include file provides support if the code is compiled on
previous VSX systems that don't have the vector pair load/store instructions.
This allows the library writer to use the same code on both power9 and power10
systems, without have to use #ifdef operations.  On a power9, the code
generated would be:

	.L66:
		lxvx 0,3,9
		lxvx 12,4,9
		lxvx 11,5,9
		xvmaddadp 0,12,11
		lxvx 12,7,9
		lxvx 11,8,9
		stxvx 0,3,9
		lxvx 0,10,9
		xvmaddadp 0,12,11
		stxvx 0,10,9
		addi 9,9,32
		bdnz .L66

With an explicit #pragma GCC unroll 2, the code generated would be:

	.L93:
		lxvx 0,3,9
		lxvx 12,4,9
		addi 10,9,32
		lxvx 11,5,9
		xvmaddadp 0,12,11
		lxvx 12,7,9
		lxvx 11,11,9
		stxvx 0,3,9
		lxvx 0,8,9
		xvmaddadp 0,12,11
		lxvx 12,4,10
		lxvx 11,5,10
		stxvx 0,8,9
		addi 9,9,64
		lxvx 0,3,10
		xvmaddadp 0,12,11
		lxvx 12,7,10
		lxvx 11,11,10
		stxvx 0,3,10
		lxvx 0,8,10
		xvmaddadp 0,12,11
		stxvx 0,8,10
		bdnz .L93

2024-11-04  Michael Meissner  <meissner@linux.ibm.com>

gcc/

	* config.gcc (powerpc*-*-*): Add vector-pair.h to extra headers.
	* config/rs6000/vector-pair.h: New file.
	* doc/extend.texi (PowerPC Vector Pair Support): Document the vector
	pair support functions.

gcc/testsuite/

	* gcc.target/powerpc/vpair-1.c: New test or include file.
	* gcc.target/powerpc/vpair-2.c: Likewise.
	* gcc.target/powerpc/vpair-3-not-p10.c: Likewise.
	* gcc.target/powerpc/vpair-3-p10.c: Likewise.
	* gcc.target/powerpc/vpair-3.h: Likewise.
	* gcc.target/powerpc/vpair-4-not-p10.c: Likewise.
	* gcc.target/powerpc/vpair-4-p10.c: Likewise.
	* gcc.target/powerpc/vpair-4.h: Likewise.
---
 gcc/config.gcc                                |   2 +-
 gcc/config/rs6000/rs6000-c.cc                 |   8 +-
 gcc/config/rs6000/vector-pair.h               | 573 ++++++++++++++++++
 gcc/doc/extend.texi                           | 100 +++
 gcc/testsuite/gcc.target/powerpc/vpair-1.c    | 150 +++++
 gcc/testsuite/gcc.target/powerpc/vpair-2.c    | 150 +++++
 .../gcc.target/powerpc/vpair-3-not-p10.c      |  15 +
 .../gcc.target/powerpc/vpair-3-p10.c          |  14 +
 gcc/testsuite/gcc.target/powerpc/vpair-3.h    | 461 ++++++++++++++
 .../gcc.target/powerpc/vpair-4-not-p10.c      |  15 +
 .../gcc.target/powerpc/vpair-4-p10.c          |  14 +
 gcc/testsuite/gcc.target/powerpc/vpair-4.h    | 461 ++++++++++++++
 12 files changed, 1960 insertions(+), 3 deletions(-)
 create mode 100644 gcc/config/rs6000/vector-pair.h
 create mode 100644 gcc/testsuite/gcc.target/powerpc/vpair-1.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/vpair-2.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/vpair-3-not-p10.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/vpair-3-p10.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/vpair-3.h
 create mode 100644 gcc/testsuite/gcc.target/powerpc/vpair-4-not-p10.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/vpair-4-p10.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/vpair-4.h

Message ID	ZykVJv6A3PKYfmHR@cowardly-lion.the-meissners.org
State	New
Headers	show Return-Path: <gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org> X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256 header.s=pp1 header.b=gUunF6Uk; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=server2.sourceware.org; envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=patchwork.ozlabs.org) Received: from server2.sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4Xj0fl5D6Cz1xwF for <incoming@patchwork.ozlabs.org>; Tue, 5 Nov 2024 05:41:19 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C52433857BA9 for <incoming@patchwork.ozlabs.org>; Mon, 4 Nov 2024 18:41:17 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 3DFE23858C5F for <gcc-patches@gcc.gnu.org>; Mon, 4 Nov 2024 18:40:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3DFE23858C5F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 3DFE23858C5F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=148.163.156.1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1730745650; cv=none; b=mSTwkZ5aAnimUGPmePN/bzDFTjDd/Fbzl12y4KYN/EgV8nWpZpJ4HCeBwQjeV07XWglocw5ZXpCjiMZ/EW8kG2uz1gmJnkEWPCGsNC19Lntil+QXwTIZW6SP1zwCPam/8X+vsN6t4Y7/l1WuOJPcm+uYZ3OLlgWC7by71HEck8Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1730745650; c=relaxed/simple; bh=SSN9iYDCMk5W6f49K/seEaC4C0XiMCbhlxfMh6zEDPM=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=EwUKhY2fBCuNT2KftSxgruIaV8CoFhDJjAFiE7WzSimGMw3WaCYdvDpuq3IOmDcD89bJmdGMRCbmarpB+9+9nGY2pUojOIYRN+XL/HdYhAENZnrtBmHjfrVQevvwereqHc/nKmxVeVgUZ4kt4kdXKXhX2CZY5QN57v+7phMoaeY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from pps.filterd (m0356517.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 4A4IeM8i007070; Mon, 4 Nov 2024 18:40:43 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h= content-type:date:from:message-id:mime-version:subject:to; s= pp1; bh=1+fa2AfJRjK0tTxFcSSzP0sIrQBovD/mpP+zKlYIP7E=; b=gUunF6Uk xkoitkfVqum1ZfIL4OmEOZ/Bu7Pi4WS4vdq2hHv/Dxx7RPyDXnz37hDnP3bauPyN 2AOC9NuSFNnpateiYO8ruIKNA0My8Wt9s3AkLVLPQQXVGvfmN87gpMmsE0LbSyTu QoRmc5Oore6FpSkTjQptdtY+Fu+istqV5xzfgZ5OnMOKI3RJnmWmDNt0NsuCTBB/ vw2sZaI0OgNI21hEOPLlti+5axJoCQ/L8Ew6q68aDeuvoDkUCSYH+r/kE++gcME0 AdB0G2WjVqI1z8Vf3uDS0PaNTcVWx0bsDthDgvW/7i+2E1dlKZG8BDOhfAPDdd+B jRbTeI+9Vz1I3Q== Received: from ppma23.wdc07v.mail.ibm.com (5d.69.3da9.ip4.static.sl-reverse.com [169.61.105.93]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 42q3rd802j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 04 Nov 2024 18:40:42 +0000 (GMT) Received: from pps.filterd (ppma23.wdc07v.mail.ibm.com [127.0.0.1]) by ppma23.wdc07v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 4A4HVZof008430; Mon, 4 Nov 2024 18:40:41 GMT Received: from smtprelay06.dal12v.mail.ibm.com ([172.16.1.8]) by ppma23.wdc07v.mail.ibm.com (PPS) with ESMTPS id 42nywk7j0w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 04 Nov 2024 18:40:41 +0000 Received: from smtpav04.dal12v.mail.ibm.com (smtpav04.dal12v.mail.ibm.com [10.241.53.103]) by smtprelay06.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 4A4IeenY54002114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 4 Nov 2024 18:40:40 GMT Received: from smtpav04.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 34F7558062; Mon, 4 Nov 2024 18:40:40 +0000 (GMT) Received: from smtpav04.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B234158063; Mon, 4 Nov 2024 18:40:39 +0000 (GMT) Received: from cowardly-lion.the-meissners.org (unknown [9.61.64.251]) by smtpav04.dal12v.mail.ibm.com (Postfix) with ESMTPS; Mon, 4 Nov 2024 18:40:39 +0000 (GMT) Date: Mon, 4 Nov 2024 13:40:38 -0500 From: Michael Meissner <meissner@linux.ibm.com> To: gcc-patches@gcc.gnu.org, Michael Meissner <meissner@linux.ibm.com>, Segher Boessenkool <segher@kernel.crashing.org>, Peter Bergner <bergner@linux.ibm.com> Subject: [PATCH, V2] PowerPC vector pair support Message-ID: <ZykVJv6A3PKYfmHR@cowardly-lion.the-meissners.org> Mail-Followup-To: Michael Meissner <meissner@linux.ibm.com>, gcc-patches@gcc.gnu.org, Segher Boessenkool <segher@kernel.crashing.org>, Peter Bergner <bergner@linux.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-TM-AS-GCONF: 00 X-Proofpoint-GUID: E2puHHqj51t-Vci3dP8PbuUxEieHNcye X-Proofpoint-ORIG-GUID: E2puHHqj51t-Vci3dP8PbuUxEieHNcye X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1051,Hydra:6.0.680,FMLib:17.12.62.30 definitions=2024-10-15_01,2024-10-11_01,2024-09-30_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 lowpriorityscore=0 clxscore=1015 mlxscore=0 suspectscore=0 bulkscore=0 spamscore=0 mlxlogscore=999 priorityscore=1501 phishscore=0 malwarescore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2409260000 definitions=main-2411040153 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> Errors-To: gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org
Series	[V2] PowerPC vector pair support \| expand [V2] PowerPC vector pair support

[V2] PowerPC vector pair support

Commit Message

Patch