diff mbox

[rs6000] Add __VEC_ELEMENT_REG_ORDER__ builtin define for PowerPC

Message ID 1408126712.25590.12.camel@gnopaine
State New
Headers show

Commit Message

Bill Schmidt Aug. 15, 2014, 6:18 p.m. UTC
Hi,

This adds a macro to indicate the order in which vector elements appear
in a register on PowerPC.  Elements may appear in right-to-left order
for little endian, or in left-to-right order for big endian and when
-maltivec=be is selected for little endian.  The same macro is being
implemented in the IBM XL compilers.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions.  Verified the new macro takes on the correct value in the
circumstances listed above.  Is this ok for trunk?  It would be
preferable to backport this to GCC 4.9 as well.

Thanks,
Bill


2014-08-15  Bill Schmidt  <wschmidt@vnet.ibm.com>

	* conifg/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Provide
	builtin define __VEC_ELEMENT_REG_ORDER__.

Comments

Alan Lawrence Aug. 20, 2014, 4:28 p.m. UTC | #1
Completely as an aside: this makes me wonder, whether having and using a similar 
macro _inside_ gcc, i.e. for targets to specify the ordering of elements within 
a vector independently of BYTES_BIG_ENDIAN, might be a good thing?

--Alan

Bill Schmidt wrote:
> Hi,
> 
> This adds a macro to indicate the order in which vector elements appear
> in a register on PowerPC.  Elements may appear in right-to-left order
> for little endian, or in left-to-right order for big endian and when
> -maltivec=be is selected for little endian.  The same macro is being
> implemented in the IBM XL compilers.
> 
> Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
> regressions.  Verified the new macro takes on the correct value in the
> circumstances listed above.  Is this ok for trunk?  It would be
> preferable to backport this to GCC 4.9 as well.
> 
> Thanks,
> Bill
> 
> 
> 2014-08-15  Bill Schmidt  <wschmidt@vnet.ibm.com>
> 
> 	* conifg/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Provide
> 	builtin define __VEC_ELEMENT_REG_ORDER__.
> 
> 
> Index: gcc/config/rs6000/rs6000-c.c
> ===================================================================
> --- gcc/config/rs6000/rs6000-c.c	(revision 214025)
> +++ gcc/config/rs6000/rs6000-c.c	(working copy)
> @@ -497,6 +497,12 @@ rs6000_cpu_cpp_builtins (cpp_reader *pfile)
>        break;
>      }
>  
> +  /* Vector element order.  */
> +  if (BYTES_BIG_ENDIAN || (rs6000_altivec_element_order == 2))
> +    builtin_define ("__VEC_ELEMENT_REG_ORDER__=__ORDER_BIG_ENDIAN__");
> +  else
> +    builtin_define ("__VEC_ELEMENT_REG_ORDER__=__ORDER_LITTLE_ENDIAN__");
> +
>    /* Let the compiled code know if 'f' class registers will not be available.  */
>    if (TARGET_SOFT_FLOAT || !TARGET_FPRS)
>      builtin_define ("__NO_FPRS__");
> 
> 
>
Bill Schmidt Aug. 20, 2014, 4:55 p.m. UTC | #2
On Wed, 2014-08-20 at 17:28 +0100, Alan Lawrence wrote:
> Completely as an aside: this makes me wonder, whether having and using a similar 
> macro _inside_ gcc, i.e. for targets to specify the ordering of elements within 
> a vector independently of BYTES_BIG_ENDIAN, might be a good thing?
> 

Yes, certainly...in fact, we have such a macro in the PowerPC backend
(VECTOR_ELT_ORDER_BIG) that we use in some cases where the target is
little endian but it is desirable to use big-endian element order (for
porting from BE PowerPC code that uses certain coding practices).
However, our macro is tied to a particular target-specific option.  If
other targets find the concept useful we'd certainly be open to a more
unified approach.

Thanks,
Bill

> --Alan
> 
> Bill Schmidt wrote:
> > Hi,
> > 
> > This adds a macro to indicate the order in which vector elements appear
> > in a register on PowerPC.  Elements may appear in right-to-left order
> > for little endian, or in left-to-right order for big endian and when
> > -maltivec=be is selected for little endian.  The same macro is being
> > implemented in the IBM XL compilers.
> > 
> > Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
> > regressions.  Verified the new macro takes on the correct value in the
> > circumstances listed above.  Is this ok for trunk?  It would be
> > preferable to backport this to GCC 4.9 as well.
> > 
> > Thanks,
> > Bill
> > 
> > 
> > 2014-08-15  Bill Schmidt  <wschmidt@vnet.ibm.com>
> > 
> > 	* conifg/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Provide
> > 	builtin define __VEC_ELEMENT_REG_ORDER__.
> > 
> > 
> > Index: gcc/config/rs6000/rs6000-c.c
> > ===================================================================
> > --- gcc/config/rs6000/rs6000-c.c	(revision 214025)
> > +++ gcc/config/rs6000/rs6000-c.c	(working copy)
> > @@ -497,6 +497,12 @@ rs6000_cpu_cpp_builtins (cpp_reader *pfile)
> >        break;
> >      }
> >  
> > +  /* Vector element order.  */
> > +  if (BYTES_BIG_ENDIAN || (rs6000_altivec_element_order == 2))
> > +    builtin_define ("__VEC_ELEMENT_REG_ORDER__=__ORDER_BIG_ENDIAN__");
> > +  else
> > +    builtin_define ("__VEC_ELEMENT_REG_ORDER__=__ORDER_LITTLE_ENDIAN__");
> > +
> >    /* Let the compiled code know if 'f' class registers will not be available.  */
> >    if (TARGET_SOFT_FLOAT || !TARGET_FPRS)
> >      builtin_define ("__NO_FPRS__");
> > 
> > 
> > 
> 
>
diff mbox

Patch

Index: gcc/config/rs6000/rs6000-c.c
===================================================================
--- gcc/config/rs6000/rs6000-c.c	(revision 214025)
+++ gcc/config/rs6000/rs6000-c.c	(working copy)
@@ -497,6 +497,12 @@  rs6000_cpu_cpp_builtins (cpp_reader *pfile)
       break;
     }
 
+  /* Vector element order.  */
+  if (BYTES_BIG_ENDIAN || (rs6000_altivec_element_order == 2))
+    builtin_define ("__VEC_ELEMENT_REG_ORDER__=__ORDER_BIG_ENDIAN__");
+  else
+    builtin_define ("__VEC_ELEMENT_REG_ORDER__=__ORDER_LITTLE_ENDIAN__");
+
   /* Let the compiled code know if 'f' class registers will not be available.  */
   if (TARGET_SOFT_FLOAT || !TARGET_FPRS)
     builtin_define ("__NO_FPRS__");