RFR(XS): Assembler::bsrl fails on assert when -UseCountLeadingZerosInstruction is used on CPU with LZCNT support
Christian Thalinger
christian.thalinger at oracle.com
Tue Mar 25 03:30:56 UTC 2014
Looks good.
On Mar 24, 2014, at 6:44 PM, Igor Veresov <igor.veresov at oracle.com> wrote:
> Alright. As we discussed I’ll just remove it.
>
> Webrev: http://cr.openjdk.java.net/~iveresov/8038222/webrev.01/
>
> igor
>
> On Mar 24, 2014, at 6:14 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>
>> From x86 docs:
>>
>> "LZCNT is an extension of the BSR instruction... On processors that do not support LZCNT, the instruction byte encoding is executed as BSR."
>>
>> So it is not oddity - it is extension. The oddity is that LZCNT code will be executed as BSR on CPUs which does not support it. Usually it should through Illegal Instruction.
>>
>> I think we can simple remove the assert because, as you said, it is wrong - we should be able generate bsr instruction together with lzcnt.
>> And we don't generate F3 prefix for BSR.
>>
>> Thanks,
>> Vladimir
>>
>> On 3/24/14 5:41 PM, Igor Veresov wrote:
>>> We have an assert here that is too strong. The problem the assert tries to guard agaist is that on x86 a bsr instruction with an f3 prefix (rep), is actually an lzcnt instruction on CPUs that support it. Actually we never do emit bsr with rep, but I relaxed that assert to verify that, just in case.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8038222
>>> Webrev: http://cr.openjdk.java.net/~iveresov/8038222/webrev.00/
>>>
>>>
>>> Thanks!
>>> igor
>>>
>
More information about the hotspot-compiler-dev
mailing list