Conditional moves vs. branching in unrolled loops

[Vitaly Davidovich]

Ideally profile pollution could be solved/improved without requiring
tiered; tiered has its own wrinkles, and many places simply use C2 alone.


On Tuesday, January 5, 2016, Remi Forax <forax at univ-mlv.fr> wrote:

> ----- Mail original -----
> > De: "John Rose" <john.r.rose at oracle.com <javascript:;>>
> > À: "Paul Sandoz" <paul.sandoz at oracle.com <javascript:;>>
> > Cc: "hotspot compiler" <hotspot-compiler-dev at openjdk.java.net
> <javascript:;>>
> > Envoyé: Mercredi 6 Janvier 2016 02:05:56
> > Objet: Re: Conditional moves vs. branching in unrolled loops
> >
> > Darn, this works against the "say what you mean" story I told for
> checkIndex.
> >
> > The bug here is very very special but is hit commonly so needs fixing.
> The
> > special part is that accumulating Math.max values over a long loop almost
> > *always* creates a series of predictable branches, which means cmov will
> > lose on many CPUs places. (Exercise: Try to construct a long series of
> > values for which each value is the largest so far, randomly, with 50%
> > probability.  This will not be a series found often in nature.)
> >
> > We need to explicitly detect accumulations on cmov ops in long loops, and
> > convert them to branches.
> >
> > Also, we should continue to recommend using intrinsics instead of random
> > logic.
> >
> > Fun fact:  Using your own branch logic makes the JVM manage a branch
> profile
> > just for you, which can mean performance. Intrinsics, if they have
> internal
> > branch logic, have polluted profiles. We need better call-site profiles
> > and/or split profiles to overcome this.
>
> we already have the first part of a kind of split profiles in tiered mode,
> if code is first inlined by c1, c2 could use these different profiles,
> but currently the profiles are shared because you have one profile for one
> bci.
>
> so in tiered more, we should have one profile by bci + caller path inside
> the same inlining blob,
> the VM need to keep the inlining tree created by c1 to send it to c2
> (there is maybe enough info in the stackwalk info to recreate the inlining
> tree).
>
> >
> > – John
>
> Rémi
>
> >
> > > On Jan 5, 2016, at 4:47 AM, Paul Sandoz <paul.sandoz at oracle.com
> <javascript:;>> wrote:
> > >
> > >
> > >> On 5 Jan 2016, at 13:00, Vitaly Davidovich <vitalyd at gmail.com
> <javascript:;>> wrote:
> > >>
> > >> This is a known issue:
> https://bugs.openjdk.java.net/browse/JDK-8039104
> > >
> > > Many thanks, i closed JDK-8146071 as a dup of JDK-8039104.
> > >
> > > Paul.
> >
>


-- 
Sent from my phone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160106/497cfe90/attachment.html>