[vector] RFR: Enable call devirtualization during post-parse phase
Viswanathan, Sandhya
sandhya.viswanathan at intel.com
Thu Jun 11 16:59:07 UTC 2020
Thanks Vladimir/Paul for clarifying this.
Best Regards,
Sandhya
-----Original Message-----
From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
Sent: Thursday, June 11, 2020 9:51 AM
To: Paul Sandoz <paul.sandoz at oracle.com>
Cc: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; panama-dev <panama-dev at openjdk.java.net>
Subject: Re: [vector] RFR: Enable call devirtualization during post-parse phase
Yes, correct.
Best regards,
Vladimir Ivanov
On 11.06.2020 19:35, Paul Sandoz wrote:
> 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_virtu
>>> al/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/m
>>> ain/java/com/openkappa/panama/vectorbenchmarks/
>
More information about the panama-dev
mailing list