Using PPC .cpu directive to help contain code generation risk?
Alan Modra
amodra@gmail.com
Fri Aug 3 23:19:00 GMT 2018
On Fri, Aug 03, 2018 at 12:12:20AM -0400, Jeffrey Walton wrote:
> 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?
The assembler directive you want is ".machine" rather than ".cpu", and
yes, the assembler will refuse to assemble power5 and above
instructions after a ".machine pwr4", provided you haven't passed
"-many" or used ".machine any". "-many" is a sticky option. Once
used you can't turn it off.
So this idea is reasonable to flag ISA problems via a hard error.
$ cat ~/src/tmp/machine.s
.machine power4
popcntb 3,3
$ as -mpower9 -o machine.o ~/src/tmp/machine.s
/home/alan/src/tmp/machine.s: Assembler messages:
/home/alan/src/tmp/machine.s:2: Error: unrecognized opcode: `popcntb'
$ as -many -o machine.o ~/src/tmp/machine.s
$
--
Alan Modra
Australia Development Lab, IBM
More information about the Binutils
mailing list