Using PPC .cpu directive to help contain code generation risk?
Jeffrey Walton
noloader@gmail.com
Fri Aug 3 04:12:00 GMT 2018
More information about the Binutils mailing list
Fri Aug 3 04:12:00 GMT 2018
- Previous message (by thread): [PATCH] Add support for DW_OP_GNU_variable_value to readelf
- Next message (by thread): Using PPC .cpu directive to help contain code generation risk?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I'm trying to find a solution to a PPC code generation issue on GCC112
from the compile farm. It is a ppc64-le machine. The problem relates
to IBM XLC compiler with the LLVM front-end.
Non-LLVM versions of XLC provided -qarch=pwr4, -qarch=pwr7,
-qarch=pwr8, etc. LLVM versions only provide -qarch=pwr8. This is a
problem for source files written for lower ISAs if the compiler
selects instructions from higher ISAs.
I was thinking I could contain the ISA cross-pollination risk with the
following. Keep in mind I have to compile with -qarch=pwr8 because
that is the only thing LLVM front-end provides.
// Test aligned vector load using PWR4
asm(".cpu pwr4 \n");
uint8x16_p v1 = vec_ld(0, b1);
// Test unaligned vector load using PWR7
asm(".cpu pwr7 \n");
uint8x16_p v2 = vec_xl(0, b2);
// Test AES encrypt using PWR8
asm(".cpu pwr8 \n");
uint8x16_p s = __vcipher(s, k);
// Back to PWR4
asm(".cpu pwr4 \n");
My question is, is this a tenable solution? Or is likely to encounter
problems over time?
Jeff
- Previous message (by thread): [PATCH] Add support for DW_OP_GNU_variable_value to readelf
- Next message (by thread): Using PPC .cpu directive to help contain code generation risk?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Binutils mailing list