Neg intrinsics for byte, short and long types
Halimi, Jean-Philippe
jean-philippe.halimi at intel.com
Sat May 5 15:34:25 UTC 2018
Yes - it actually works pretty well. It generates better code, I think. As Razvan mentioned the xor gets hoisted out of the loop which is also good.
I only enabled this technique for integral types because it generates -0.0f instead of 0.0f for floating point. As the intrinsics are already implemented, all types are covered now.
Let me know what you think, here is the new webrev:
http://cr.openjdk.java.net/~jphalimi/webrev_neg_byte_short_long_v1.4/webrev/
Thanks,
Jp
-----Original Message-----
From: Lupusoru, Razvan A
Sent: Tuesday, May 1, 2018 4:50 PM
To: Paul Sandoz <paul.sandoz at oracle.com>; Halimi, Jean-Philippe <jean-philippe.halimi at intel.com>
Cc: panama-dev at openjdk.java.net
Subject: RE: Neg intrinsics for byte, short and long types
Seems reasonable to me to do it this way - should be easy to try that it optimizes in same way. Would you be able to try it JP?
Thanks,
Razvan
-----Original Message-----
From: panama-dev [mailto:panama-dev-bounces at openjdk.java.net] On Behalf Of Paul Sandoz
Sent: Tuesday, May 01, 2018 9:08 AM
To: Halimi, Jean-Philippe <jean-philippe.halimi at intel.com>
Cc: panama-dev at openjdk.java.net
Subject: Re: Neg intrinsics for byte, short and long types
> On May 1, 2018, at 4:58 AM, Halimi, Jean-Philippe <jean-philippe.halimi at intel.com> wrote:
>
> Good catch! It looks like the template got indeed corrupted in a rebase.
>
> Here is the updated webrev:
> http://cr.openjdk.java.net/~jphalimi/webrev_neg_byte_short_long_v1.3/
>
Much better :-)
> Otherwise, I do not see any reason why we could not implement neg as you described, however I am not sure why we should?
>
I was thinking that we might be able to reduce the amount of HotSpot code that needs to be maintained as each operation can add a non-trivial amount code (even if that is similar of patterns to other code).
Paul.
> @Razvan, what are your thoughts?
>
> Thanks,
>
> Jp
>
> -----Original Message-----
> From: Paul Sandoz [mailto:paul.sandoz at oracle.com]
> Sent: Monday, April 30, 2018 4:13 PM
> To: Halimi, Jean-Philippe <jean-philippe.halimi at intel.com>
> Cc: panama-dev at openjdk.java.net
> Subject: Re: Neg intrinsics for byte, short and long types
>
> X-VectorBits.java.template
> —
>
> The template looks out of sync with the generated code.
>
> E.g. "#end[intOrFP]” moved from line 379 to line 350.
>
>
> Just a thought. I suppose we could have implemented neg in the concrete Vector implementations as:
>
> SPECIES.zero().sub(this);
>
> Can that produce similar code as vpxor and vpsub* ?
>
> Thanks,
> Paul.
>
>> On Apr 30, 2018, at 9:39 AM, Halimi, Jean-Philippe <jean-philippe.halimi at intel.com> wrote:
>>
>> Hi all,
>>
>> I would like to share a patch adding support for neg intrinsic for byte, short and long types in VectorAPI.
>>
>> Could you please review the patch here:
>> http://cr.openjdk.java.net/~jphalimi/webrev_neg_byte_short_long_v1.2/
>>
>> Please let me know your thoughts!
>>
>> Thank you,
>>
>> Jp
>
More information about the panama-dev
mailing list