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 <wschm...@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__");
