[PPC64LE] Implement little-endian semantics for vec_unpack[hl]
authorBill Schmidt <wschmidt@linux.vnet.ibm.com>
Sat, 7 Jun 2014 02:20:52 +0000 (02:20 +0000)
committerBill Schmidt <wschmidt@linux.vnet.ibm.com>
Sat, 7 Jun 2014 02:20:52 +0000 (02:20 +0000)
commitd7c53a91dfe4534b93aee234a41dc7ea13d5df33
tree0b22e72819a40914fca590a579acf7c27ba62d8c
parent7f1ebbeb8fdcae821ec5ae32d3bcb6c428016663
[PPC64LE] Implement little-endian semantics for vec_unpack[hl]

The PowerPC vector-unpack-high and vector-unpack-low instructions
are defined architecturally with a big-endian bias, in that the vector
element numbering is assumed to be "left to right" regardless of
whether the processor is in big-endian or little-endian mode.  This
effectively reverses the meaning of "high" and "low."  Such a
definition is unnatural for little-endian code generation.

To facilitate ease of porting, the vec_unpackh and vec_unpackl
interfaces are designed to use natural element ordering, so that
elements are numbered according to little-endian design principles
when code is generated for a little-endian target.  The desired
semantics can be achieved by using the opposite instruction for
little-endian mode.  That is, when a call to vec_unpackh appears in
the code, a vector-unpack-low is generated, and when a call to
vec_unpackl appears in the code, a vector-unpack-high is generated.

The correctness of this code is tested by the new unpack.c test
added in a previous patch, as well as the modifications to
builtins-ppc-altivec.c in the present patch.

Note that these interfaces were originally incorrectly implemented
when they take a vector pixel argument.  This patch corrects this
implementation for both big- and little-endian code generation.

llvm-svn: 210391
clang/lib/Headers/altivec.h
clang/test/CodeGen/builtins-ppc-altivec.c