RFR: Add support of lzcnt and tzcnt

[Igor Veresov]

So, is this one ok?
(http://cr.openjdk.java.net/~iveresov/lztzcnt/webrev.02 <http://cr.openjdk.java.net/~iveresov/lztzcnt/webrev.02>)

igor

> On Nov 17, 2014, at 8:49 PM, Igor Veresov <igor.veresov at oracle.com> wrote:
> 
> Thomas,
> 
> Thanks for the advice! I moved the substitutions to c.o.g.hotspot.
> Here is the updated webrev: http://cr.openjdk.java.net/~iveresov/lztzcnt/webrev.02
> 
> Thanks!
> igor
> 
>> On Nov 17, 2014, at 3:30 PM, Thomas Wuerthinger <thomas.wuerthinger at oracle.com> wrote:
>> 
>> Igor,
>> 
>> Another possibility is to move the registration of AMD64IntegerSubstitutions and AMD64LongSubstitutions to the HotSpotSubstitutions class and guard these registrations with checking the flag from HotSpotVMConfig there. If I understand the patch correctly, then the substitutions themselves are independent of the VM and only the configuration whether they should be used or not depends on code specific to HotSpot.
>> 
>> In general, we mark HotSpot specific modules with “hotspot”, platform specific packages with “amd64”, “ptx”, “sparc” or “hsail”, and package specific to testing with “test”. A more general module must never depend on a more specific module. A module may be specific in more than one dimension, "com.oracle.graal.hotspot.amd64.test” is for example a testing package specific to HotSpot and AMD64. A module marked with “api” can only depend on other modules marked with “api”. We should probably enforce these rules in the mx script. You can see our full dependency graph at http://lafo.ssw.uni-linz.ac.at/javadoc/graalvm/all/projects.jpg <http://lafo.ssw.uni-linz.ac.at/javadoc/graalvm/all/projects.jpg>.
>> 
>> - thomas
>