RFR 8199843 : Optimize Integer/Long.highestOneBit()

Ivan Gerasimov ivan.gerasimov at oracle.com
Mon Mar 26 21:26:04 UTC 2018


Thank you Andrew for looking into this!


On 3/24/18 4:13 AM, Andrew Haley wrote:
> 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.
This looks persuasive, so let's go ahead with the branchless variant!

With kind regards,
Ivan

> 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.
>

-- 
With kind regards,
Ivan Gerasimov



More information about the core-libs-dev mailing list