Implicit null-check in hot-loop?

[Benedikt Wedenik]

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/af2fff00/attachment.html>