]> granicus.if.org Git - clang/commit
[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)
commit61d8772216d8e932b08ed0eb4fa3542592e8f4cb
tree4654e34d288114a1233ba404e041b44137534e55
parent63188e765f09ae7eb8b0932d848ecc87b148b7af
[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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210391 91177308-0d34-0410-b5e6-96231b3b80d8
lib/Headers/altivec.h
test/CodeGen/builtins-ppc-altivec.c