[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-graal-dev
Subject:    Re: RFR: Add support of lzcnt and tzcnt
From:       Thomas Wuerthinger <thomas.wuerthinger () oracle ! com>
Date:       2014-11-19 21:51:57
Message-ID: A230FD8E-02EF-4294-A082-9659812B3297 () oracle ! com
[Download RAW message or body]

Sounds great! Thanks for your contribution!

- thomas


On 19 Nov 2014, at 21:17, Igor Veresov <igor.veresov@oracle.com> wrote:

> Gilles,
> 
> Thanks a lot!
> 
> I’d rather proceed incrementally. I’ll add extended substitution guards and \
> refactor this in the next change. 
> igor
> 
> > On Nov 19, 2014, at 4:15 AM, Gilles Duboscq <duboscq@ssw.jku.at> wrote:
> > 
> > I'll integrate it as-is though and we can refine this later.
> > 
> > -Gilles
> > 
> > On Wed, Nov 19, 2014 at 12:15 PM, Gilles Duboscq <duboscq@ssw.jku.at> wrote:
> > > 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@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@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@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
> > > > > 
> > > > 
> 


[prev in list] [next in list] [prev in thread] [next in thread]