Neg intrinsics for byte, short and long types

[Paul Sandoz]

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