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