VectorAPI Testing Infrastructure custom loop trip count

[Halimi, Jean-Philippe]

I agree that we might want to focalize the stress on the compute kernel itself. Doing so involves re-assigning values tested in the assert method.
I do see advantages especially if we want to use jmh to add performance analysis capabilities in the future.

I have done a quick rework of the patch to keeps the assert out-of-loop. Let me know which one looks best for you.

http://cr.openjdk.java.net/~jphalimi/webrev_testing_trip_count_v1.1/webrev/ 

Thanks,

Jp

-----Original Message-----
From: Paul Sandoz [mailto:paul.sandoz at oracle.com] 
Sent: Monday, April 2, 2018 11:37 AM
To: Halimi, Jean-Philippe <jean-philippe.halimi at intel.com>
Cc: panama-dev at openjdk.java.net
Subject: Re: VectorAPI Testing Infrastructure custom loop trip count



> On Apr 2, 2018, at 8:13 AM, Halimi, Jean-Philippe <jean-philippe.halimi at intel.com> wrote:
> 
> Dear all,
> 
> The following link is a patch adding support for a custom trip count for each test in the testing infrastructure.
> 
> http://cr.openjdk.java.net/~jphalimi/webrev_testing_trip_count_v1.0/webrev/
> 
> Please take a look and let me know your thoughts.
> 

Do you have any views on whether the outer loop should cover just the kernel loop, or also include the allocation and assertion as in your patch?

I am unsure, but my suspicion it may be more more beneficial if it covers just the kernel loop so C2 is focused on the kernel, then allocation/assert code has less influence on the code shape.
 
Assuming the operations are deterministic, my suspicion is we are more interested in the correctness of a C2 produced code and less so on the intermediate results, which i think we can get coverage on with intrinsics off and/or with tiered compilation/C1 only.

Maybe later we configure what is in and outside the loop?

Paul.