[vector] RFR: Enable call devirtualization during post-parse phase

[Paul Sandoz]

Hi Vladimir,

To be clear, you are not proposing that this code, when integrated to vectorIntrinsics, needs to be merged to vector-unstable?

If it so happens to make it’s way upstream before we integrate then that’s nice, but otherwise the effect is we just have to be careful when merging to vector-unstable for any updates in response to review comments. Correct?

Paul.

> On Jun 11, 2020, at 9:14 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> 
> Thanks for the review, Sandhya.
> 
>> Thanks for looking into this. Please go ahead and push.
>> I think we could include this as part of Vector API work if it is ok with you.
>> That way you don’t have to upstream it separately and then re-merge. Also, it shortens our dependencies.
> 
> Unless the optimization is limited to Vector API, I'm afraid it'll raise some concerns and complicate review process. That's why I'm in favor of upstreaming it separately.
> 
> The main motivation to get it fixed in vectorIntrinsics branch first is to unblock some experiments people are conducting.
> 
>> We are thinking of asking next round of reviews immediately after the fork for JDK 15 and hopefully "Propose to Target" to 16 soon thereafter.
> 
> IMO the problem shouldn't be a stopper for the initial integration and it's fine to fix it afterwards.
> 
> Best regards,
> Vladimir Ivanov
> 
>> -----Original Message-----
>> From: panama-dev <panama-dev-bounces at openjdk.java.net> On Behalf Of Vladimir Ivanov
>> Sent: Tuesday, June 09, 2020 3:36 PM
>> To: panama-dev <panama-dev at openjdk.java.net>
>> Subject: [vector] RFR: Enable call devirtualization during post-parse phase
>> http://cr.openjdk.java.net/~vlivanov/panama/vector/late_inline_virtual/webrev.00/
>> Vector API refactoring broke inlining through virtual calls in some important scenarios (for example, both dot product and matrix multiplication samples [1] are affected [1]).
>> The primary root cause is the delay in intrinsification of vector
>> operations: unless enough type info is available for receiver during parsing, the call won't be devirtualized (and hence inlined), but intrinsification happens during post-parse phase.
>> However, it turned out that the problem is broader and not specific to Vector API. It's not enough just to intrinsify vector operations eagerly.
>> Proposed patch is an experimental implementation of post-parse devirtualization (virtual-to-direct call transformation) which then enables post-parse inlining & intrinsification through such calls.
>> I'll work on upstreaming the optimization separately since it benefits ordinary Java code as well. Meanwhile, I propose to integrate the interim version into vectorIntrinsics branch right away to avoid surprises during performance analysis.
>> Best regards,
>> Vladimir Ivanov
>> [1]
>> https://github.com/richardstartin/vectorbenchmarks/blob/master/src/main/java/com/openkappa/panama/vectorbenchmarks/