RFR: Add support of lzcnt and tzcnt

[Igor Veresov]

Hi Gilles,

Thanks for the review!
Please find the replies inline.

> On Nov 15, 2014, at 4:06 AM, Gilles Duboscq <duboscq at ssw.jku.at> wrote:
> 
> Hi Igor,
> 
> -BitScanForwardNode.inferStamp:
> looks like firstMaybeSetBit and min can now be set outside of the if/else

Good point. Fixed.

> -BitOpsTest:
> You could have used UnsafeAccess
> 
Aha, thanks for pointing that out. I grepped for something like it but didn’t notice UnsafeAccess. Fixed.

> The rest looks good to me. Thanks.

Updated webrev: http://cr.openjdk.java.net/~iveresov/lztzcnt/webrev.01/

> 
> Overall, it looks like we should rather use the Count*ZerosNode at the
> high level regardless of the platform and lower them in a
> platform-dependent way. On AMD64 without lzcnt/tzcnt we would then
> introduce the BitScan* nodes only during platform-dependent lowering.
> We should put that on the todo-list if we introduce a proper
> platform-specific lowering phase before LIR.

It’s a possible approach, I liked substitution guards though. They are fairly expressive.  May be we can allow a form of substitution specialization, in which there is a generic implementation and then we can define a specialized version for some platform that will automatically replace it. I guess it may be achieved, for example, by prioritizing replacement providers.

igor


> 
> -Gilles
> 
> On Sat, Nov 15, 2014 at 8:30 AM, Igor Veresov <igor.veresov at oracle.com> wrote:
>> The change adds the following:
>> - support of lzcnt and tzcnt instructions,
>> - unit tests for lzcnt/tzcnt,
>> - ability to emit bsf/bsr in case lzcnt/tzcnt were turned off from the command line,
>> - tightening the stamps produced by ScanBitForward/ReverseNode nodes.
>> 
>> 
>> Webrev: http://cr.openjdk.java.net/~iveresov/lztzcnt/webrev.00/
>> 
>> Thanks!
>> igor