RFR 8199843 : Optimize Integer/Long.highestOneBit()

[Andrew Haley]

On 03/20/2018 05:20 PM, Ivan Gerasimov wrote:
> I tried to run it, but the numbers are non-distinguishable for non-zero 
> arguments.
> And my variant performs slightly better with zero argument.
> So, I think it's reasonable to keep the variant with the ternary operator.

I am suspicious of this argument.  Did you look at the generated code?

I get

   cbnz	w10, 0x000003ffa8202384
   mov	w0, wzr

for the zero test and

   cbz	w10, 0x000003ffa81d228c
   clz	w11, w10
   orr	w10, wzr, #0x80000000
   lsr	w0, w10, w11    ;*iushr

for 42.

The branch at the start of both versions goes to a deoptimize trap.
We don't want deoptimize traps if we can avoid them, so the branchless
version is better IMO.

I think your benchmark is of questionable validity because it always
uses the same value.  This is unlikely in real code.  I think the
versions should be benchmarked with a *varying* argument.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671