RFR: Add support of lzcnt and tzcnt
Gilles Duboscq
duboscq at ssw.jku.at
Wed Nov 19 11:15:43 UTC 2014
It's a bit strange to put something that it platform-specific only
into a vm-speific only project. It means that now other VMs will to be
able to use those instructions or will need to re-implement the nodes
& substitution.
Can't we make hotspot just mask the CPUFeature flags like we do for
the other flags (as suggested by yourself and Christian above)?
-Gilles
On Wed, Nov 19, 2014 at 4:16 AM, Igor Veresov <igor.veresov at oracle.com> wrote:
> 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
>>
>
More information about the graal-dev
mailing list