On 2020-06-24 4:25 p.m., Andrew Hughes wrote:
On 22/06/2020 10:00, Andrew Haley wrote:
On 18/06/2020 19:33, Martin Balao wrote:
snip...
* L3724
* The last argument of 'sub' has type 'int', while in the not-Windows
variant is a long. Can we align this?
We should do that, yes. Better
On 22/06/2020 10:00, Andrew Haley wrote:
> On 18/06/2020 19:33, Martin Balao wrote:
snip...
>> * L3724
>>* The last argument of 'sub' has type 'int', while in the not-Windows
>> variant is a long. Can we align this?
>
> We should do that, yes. Better it be long everywhere.
>
Patch looks
On 18/06/2020 19:33, Martin Balao wrote:
> * sharedRuntime_x86_64.cpp
> * L3685
>* Do we still need 'long long' type for 'i' and 'cnt' local variables?
No, but this is 64-bit-only code. And len is a long, so let's keep it.
> * L3724
>* The last argument of 'sub' has type 'int', while
Hi,
On 6/5/20 5:46 PM, Simon Tooke wrote:
> Please let me know what you think.
>
> updated webrev:
> http://cr.openjdk.java.net/~stooke/webrevs/jdk-8243114-jdk/01/01/
>
Overall, the intrinsics looks good to me.
A few minor comments:
* sharedRuntime_x86_64.cpp
* L3685
* Do we still need
On 05/06/2020 21:46, Simon Tooke wrote:
> As per your and Andrew Haley's comments, I have updated the webrev:
>
> - used NOINLINE
>
> - used julong
>
> - deleted the block of unused code.
>
> Please let me know what you think.
>
> updated webrev:
> http://cr.openjdk.java.net/~stooke/webrevs/j
Hi Simon,
On 6/06/2020 6:46 am, Simon Tooke wrote:
Thanks again for the review.
As per your and Andrew Haley's comments, I have updated the webrev:
- used NOINLINE
- used julong
- deleted the block of unused code.
Please let me know what you think.
updated webrev:
http://cr.openjdk.java.n
Thanks again for the review.
As per your and Andrew Haley's comments, I have updated the webrev:
- used NOINLINE
- used julong
- deleted the block of unused code.
Please let me know what you think.
updated webrev:
http://cr.openjdk.java.net/~stooke/webrevs/jdk-8243114-jdk/01/01/
Thanks,
On 05/06/2020 05:35, David Holmes wrote:
> If these arrays are extracted from Java arrays
Yes, they are.
> then using a j* type would be appropriate, but then I would expect
> jlong, unless the algorithm explicitly requires unsigned types?
It does. All of the code handling bignums uses unsigned
Hi Simon,
On 4/06/2020 11:35 pm, Simon Tooke wrote:
Hello, David, and thanks for the review!
I've responded to your comments below, and intend to post a new patch
for review today or tomorrow.
Thanks again,
-Simon
On 2020-06-03 2:06 a.m., David Holmes wrote:
Hi Simon,
On 23/05/2020 12:04
On 04/06/2020 14:35, Simon Tooke wrote:
> Yes, this hurt to type. A previous review suggested using julong, is
> that acceptable to you?
>
> (an aside: I'm now wondering if there is other code in the JDK that
> assumes long is 64bits - which is not true on all platforms...)
That was just me, I
Hello, David, and thanks for the review!
I've responded to your comments below, and intend to post a new patch
for review today or tomorrow.
Thanks again,
-Simon
On 2020-06-03 2:06 a.m., David Holmes wrote:
Hi Simon,
On 23/05/2020 12:04 am, Sean Mullan wrote:
Cross-posting to hotspot-dev f
Hi Simon,
On 23/05/2020 12:04 am, Sean Mullan wrote:
Cross-posting to hotspot-dev for additional review since the code
changes are in hotspot.
--Sean
On 5/21/20 1:24 PM, Simon Tooke wrote:
Hello,
I'd like to request a review for:
JBS: https://bugs.openjdk.java.net/browse/JDK-8243114
Webre
On 21/05/2020 18:24, Simon Tooke wrote:
> This change implements the given intrinsics on Windows.
Thank you.
Does julong work on Windows, rather than unsigned long long? If not,
perhaps a local typedef might help. All those "unsigned log long"s
look a bit clumsy.
--
Andrew Haley (he/him)
Java
Cross-posting to hotspot-dev for additional review since the code
changes are in hotspot.
--Sean
On 5/21/20 1:24 PM, Simon Tooke wrote:
Hello,
I'd like to request a review for:
JBS: https://bugs.openjdk.java.net/browse/JDK-8243114
Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-82431
14 matches
Mail list logo
