Implicit null-check in hot-loop?

[Vitaly Davidovich]

I don't think there's any fundamental reason, it's just that int loops are
more common and so were optimized.

sent from my phone
On May 27, 2015 8:09 AM, "Benedikt Wedenik" <
benedikt.wedenik at theobroma-systems.com> wrote:

> First of all, thanks for your quick response :)
> You were absolutely right - but I do not understand why the long counter
> was the problem.
>
> Is there any reason why the loop-unrolling is only available for int loops?
> I mean I guess so - because else it would probably be implemented already.
> But still it would be a nice opportunity for an optimisation :)
>
> Benedikt.
> On 27 May 2015, at 13:44, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
> Also, the safepoint check on each iteration should go away when using an
> int loop; it'll be coalesced into once per unroll factor or may go away
> entirely if the loop turns into a counted loop.
>
> sent from my phone
> On May 27, 2015 7:39 AM, "Vitaly Davidovich" <vitalyd at gmail.com> wrote:
>
>> Cause you're using a long as induction variable; change to int and it
>> should unroll.
>>
>> sent from my phone
>> On May 27, 2015 6:46 AM, "Benedikt Wedenik" <
>> benedikt.wedenik at theobroma-systems.com> wrote:
>>
>>> Oh!
>>>
>>> Thanks :) So then it's not so bad, cause it is (I guess) obligatory.
>>>
>>> Do you have any idea why this loop does not get unrolled?
>>>
>>> Benedikt.
>>>
>>> On 27 May 2015, at 12:36, Andrew Haley <aph at redhat.com> wrote:
>>>
>>> > On 05/27/2015 11:27 AM, Benedikt Wedenik wrote:
>>> >>
>>> >> In the hot-loop there is this “ldr” which looked a little “strange”
>>> at the first glance.
>>> >> I think that this load is a null-check? Is that the case?
>>> >
>>> > No.  It's a safepoint check.  HotSpot has to insert one of these
>>> because
>>> > it can't prove that the loop is reasonably short-lived.
>>> >
>>> >> I also investigated the generated code on x86 which is quite similar,
>>> but instead of a load, they are
>>> >> using the “test”-instruction which performs an “and” but only sets
>>> the flags discarding the result.
>>> >> Is there any similar instruction available on aarch64 or is this
>>> already the closest solution?
>>> >
>>> > Closest to what?  A load to XZR is the best solution: it does not hit
>>> > the flags.  x86 cannot do this.
>>> >
>>> > It looks like great code.
>>> >
>>> > Andrew.
>>> >
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150527/1440f25d/attachment.html>