Message ID | 1408126712.25590.12.camel@gnopaine |
---|---|
State | New |
Headers | show |
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__"); > > >
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__"); > > > > > > > >
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__");