[vector] tests with data providers

[Vladimir Ivanov]

Thanks for the clarification, Paul.

I missed that you don't parameterize operations. The change looks good then.

The only difference I see is with true/false masks:

-        Vector.Mask<Integer, Shapes.S256Bit> tMask = species.trueMask();
-        Vector.Mask<Integer, Shapes.S256Bit> fMask = species.falseMask();

Those operations are intrinsified [1] and after your change the masks 
will be loaded from memory instead of materialized from a constant.

But that's fine.

Best regards,
Vladimir Ivanov

[1] 
http://hg.openjdk.java.net/panama/dev/file/67e56a87d736/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java#l1044

On 15/03/2018 01:32, Paul Sandoz wrote:
> 
> 
>> On Mar 14, 2018, at 3:27 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>>
>> Paul,
>>
>>> Patch rebased and updated for the comparison methods:
>>>    http://cr.openjdk.java.net/~psandoz/panama/tests-with-data-providers/webrev/
>>
>> Have you looked into how new tests are optimized by C2?
>>
> 
> No.
> 
> The generators return arrays and i am not parameterizing the scalar operation, so the actual kernel is unchanged e.g.:
> 
> @Test(dataProvider = "intBinaryOpMaskProvider", invocationCount = 10)
> static void addInt256VectorTests(IntFunction<int[]> fa, IntFunction<int[]> fb,
>                                        IntFunction<boolean[]> fm) {
>      int[] a = fa.apply(SPECIES.length());
>      int[] b = fb.apply(SPECIES.length());
>      int[] r = new int[a.length];
>      boolean[] mask = fm.apply(SPECIES.length());
>      Vector.Mask<Integer, Shapes.S256Bit> vmask = SPECIES.constantMask(mask);
> 
>      // Computation.
>      for (int i = 0; i < a.length; i += SPECIES.length()) {
>          IntVector<Shapes.S256Bit> av = SPECIES.fromArray(a, i);
>          IntVector<Shapes.S256Bit> bv = SPECIES.fromArray(b, i);
>          av.add(bv, vmask).intoArray(r, i);
>      }
> 
>      assertArraysEquals(a, b, r, mask, Int256VectorTests::add);
> }
> 
> do you see any issue with that approach?
> 
> Paul.
> 
>> My main concern is that the generators are opaque to the compiler. It won't break intrinsification, but vector intructions will reside in tiny stand-alone methods and there'll be excessive boxing/unboxing happening unless C2 is able to inline the operations.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>>>> On Mar 9, 2018, at 5:12 PM, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Please review this patch to covert the vector tests to use TestNG data providers:
>>>>
>>>>   http://cr.openjdk.java.net/~psandoz/panama/tests-with-data-providers/webrev/ <http://cr.openjdk.java.net/~psandoz/panama/tests-with-data-providers/webrev/>
>>>>
>>>> For now i took the simplest route placing them in the concrete tests rather than in a super class for a type shared across the shapes (in effect much in the header.template can be moved over to such a super class).
>>>>
>>>> Paul.
>