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

[Vladimir Ivanov]

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