Implicit null-check in hot-loop?

[Vladimir Kozlov]

There is reason. We do long arithmetic to prove that int index will not overflow in canonical (counted) loops but we 
can't do that cheaply for long index. And 99% of loops use int index - so we don't want to spend code on edge case.

Regards,
Vladimir


On 5/27/15 5:25 AM, Vitaly Davidovich wrote:
> 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
> <mailto: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 <mailto: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 <mailto: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
>>         <mailto: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 <mailto: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.
>>             >
>>
>