[PATCH, test-suite] Add some Altivec execution tests

[Bill Schmidt]

Committed as r201277.  Thanks for the review!

Bill

On Thu, 2014-06-05 at 11:38 -0500, Hal Finkel wrote:
> This LGTM. Please add these tests to the exclusion list in SingleSource/UnitTests/Vector/Altivec/Makefile for when BENCHMARKING_ONLY is defined.
> 
> Obviously, we'll also need clang/llvm-level regression tests with the corresponding PPC-LE implementation (but I like having runtime tests too).
> 
>  -Hal
> 
> ----- Original Message -----
> > From: "Bill Schmidt" <wschmidt at linux.vnet.ibm.com>
> > To: llvm-commits at cs.uiuc.edu
> > Cc: hfinkel at anl.gov
> > Sent: Wednesday, June 4, 2014 10:57:41 PM
> > Subject: [PATCH, test-suite] Add some Altivec execution tests
> > 
> > [PATCH, test-suite] Add some Altivec execution tests
> > 
> > The PowerPC VMX instruction set (also known as Altivec) contains a
> > number of instructions that have a "big-endian bias"; that is, they
> > implicitly or explicitly assume that vector elements are numbered
> > "left to right" within a vector register.  These instructions
> > therefore do not behave naturally when code is generated for a little
> > endian target.
> > 
> > These, as well as the better-behaved Altivec instructions, may be
> > accessed through interfaces defined in <altivec.h>.  For ease of
> > porting, it is desirable that the Altivec instructions behave as a
> > programmer would expect for little endian code generation, rather
> > than
> > how the underlying instructions actually work.
> > 
> > As an example, the vec_mule interface is used to perform a widening
> > multiply on even elements of a vector.  The even elements, when
> > numbered in little-endian element order, are the same as the odd
> > elements when numbered in big-endian element order.  Therefore when
> > vec_mule is specified in a program, the proper effect is obtained by
> > generating a vector-multiply-even for a big-endian target, but
> > instead
> > generating a vector-multiply-odd for a little-endian target.
> > 
> > I will be submitting a number of patches to implement these changes
> > for little-endian code generation.  For the present, I want to add a
> > number of new test cases that will test the correct behavior of the
> > endian-sensitive Altivec instructions for both big- and little-endian
> > targets.
> > 
> > The new tests in this patch are self-testing; they will abort if the
> > instructions produce a wrong result.  It seemed to me the best place
> > to put these tests was with the other run-time Altivec tests, i.e.,
> > in
> > projects/test-suite/SingleSource/UnitTests/Vector/Altivec.  In
> > keeping
> > with the behavior of the existing tests, I've included reference
> > output files for each test; however, these are minimal ("exit 0\n")
> > because of the self-testing nature of the tests.  Please let me know
> > if there is a better place to put these tests, or any additional
> > materials I need to provide.
> > 
> > All of these tests currently run correctly on big-endian PPC64
> > targets, with the exception of unpack.c.  This is because the current
> > implementations of vec_unpackh and vec_unpackl with a vector pixel
> > argument do not generate correct code.  This will be fixed in a
> > follow-on patch that addresses the little endian implementations of
> > vec_unpack[hl].
> > 
> > Please let me know whether these tests are ok to commit.
> > 
> > Thanks,
> > Bill
> > 
>