RFR: 8216392: Enable cmovP_mem and cmovP_memU instructions

B. Blaser bsrbnd at gmail.com
Sat Jan 19 13:42:24 UTC 2019

On Fri, 18 Jan 2019 at 14:37, Roman Kennke <rkennke at redhat.com> wrote:
> > On 1/17/19 7:51 PM, B. Blaser wrote:
> >> Here it is on intel xeon with 5*10e9 iterations:
> >> * mov+cmov = 10.94s
> >> * cmov = 10.15s
> >>
> >> Thoughts?
> >
> > It looks like there's not much of a performance difference, but it might
> > help by freeing a register. OTOH, we'd still need to be sure we weren't
> > introducing a regression. We'd have to make sure that implicit null checks
> > work.
> I'm pretty sure that null-checks work, in general. I used the cmov
> instructions in an experiment that I did with Shenandoah barriers of
> which I'm pretty sure would have blown up badly if it wouldn't. One
> thing I'm not sure of is: does cmov generate a SIGSEGV on a bad address,
> even if the condition is not true? I doubt it, because then we couldn't
> use this for other types (long, int, etc).
> I'm more worried about the bottom-type issue that is mentioned in the
> comment and by Andrew Dinn, and it would be very helpful if anybody
> knows about it and could clarify. Failing that we could dig deeper
> and/or do extensive testing?

I'm definitely not an expert in this area but does ADLC treat this
really differently from a single LoadP / mov?



More information about the hotspot-compiler-dev mailing list