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