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

Bill Schmidt wschmidt at linux.vnet.ibm.com
Thu Jun 5 10:25:15 PDT 2014


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).

Thanks, Hal!  Agreed about the additional regression tests.  My plan is
to work on getting some of the existing Altivec regression tests
functional for ppc64 as well as ppc64le.  These have always only run on
ppc32, which is a hole in the current testing.

The run-time tests will give us a solid basis for knowing the code is
working until those updates are completed.

Thanks again,
Bill

> 
>  -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
> > 
> 




More information about the llvm-commits mailing list