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