VectorAPI Testing Infrastructure custom loop trip count

Halimi, Jean-Philippe jean-philippe.halimi at
Thu Apr 5 14:40:53 UTC 2018

Sorry for the delayed answer. I totally agree. For some reason, I assumed that the iterations had some kind of write dependencies but you are right, they don’t. ☺
I have merged the original patch and I have rebased this latest revision with the fixes you suggested.

As for the compare tests, I agree. If I recall correctly, @Razvan made these tests this way for one specific reason. Any thoughts Razvan?

Let me know what you think,


From: Paul Sandoz [mailto:paul.sandoz at]
Sent: Tuesday, April 3, 2018 8:56 AM
To: Halimi, Jean-Philippe <jean-philippe.halimi at>
Cc: panama-dev at
Subject: Re: VectorAPI Testing Infrastructure custom loop trip count

On Apr 3, 2018, at 7:35 AM, Halimi, Jean-Philippe <jean-philippe.halimi at<mailto:jean-philippe.halimi at>> wrote:

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.

   9         $type$[] a = null;

  10         $type$[] b = null;

  11         $type$[] r = null;

  12         boolean[] mask = null;

  13         for (int ic = 0; ic < INVOC_COUNT; ic++) {

  14             a = fa.apply(SPECIES.length());

  15             b = fb.apply(SPECIES.length());

  16             r = new $type$[a.length];

  17             mask = fm.apply(SPECIES.length());

Why don’t you move the allocations out of the invocation loop as well?

The inputs are never modified and the result will just get overwritten, it should not matter what its prior contents were.

We are assuming that storing into the array works correctly (e.g. no weird bug eliding stores) and we should have separate tests focused on loads/stores to increase our trust.


Separately, maybe we should revisit the compare tests later on to try and pull out the assert from the kernel loop.


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.



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

On Apr 2, 2018, at 8:13 AM, Halimi, Jean-Philippe <jean-philippe.halimi at<mailto:jean-philippe.halimi at>> wrote:

Dear all,

The following link is a patch adding support for a custom trip count for each test in the testing infrastructure.

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?


More information about the panama-dev mailing list