From tom.rodriguez at oracle.com Wed Mar 1 00:39:19 2017 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 28 Feb 2017 16:39:19 -0800 Subject: RFR: AArch64: Implementing address lowering to make use of immediate address mode In-Reply-To: <206f2ccf-7e37-1b7b-3f30-7b319ddb6534@redhat.com> References: <206f2ccf-7e37-1b7b-3f30-7b319ddb6534@redhat.com> Message-ID: <58B61837.60107@oracle.com> There's nothing about the AddressLoweringPhase that says the mapping of old the OffsetAddressNode to machine dependent address mode must be one to one. You are free to examine the usages and generate a distinct address node for each use. GVN will common any duplicates back together. You still will need to select the right forms for the backend so it doesn't address all the problems you mention. tom Andrew Dinn wrote: > I have patched (a slightly out of date version of) Graal to allow > AArch64 to make use of scaled and unscaled immediate addressing. This > generates much better code but the implementation is 'wrong' in several > important respects. A pull request including the change is available here > > https://github.com/graalvm/graal-core/pull/258 > > I have no wish for this change to be included as is - I posted it merely > to enable discussion of what is really needed. > > The patch deliberately bypasses the normal AddressLowering phase (I'll > explain why in a second). Instead it intercepts translation of addresses > during the generate phase. Basically, it attempts to improve addresses > initially generated as an OffsetAddress (i.e. supplied with 2 Values, > base and index) when the index is an integer constant whcih can be > embedded as an immediate displacement (I guess it ought to handle the > reverse case where base is a constant and index a general Value but > nothing appears to be generating addresses with constants in that > order). It does so by 'nulling' the index saving the constant as a > displacement and resetting the addressing mode from register offset to > scaled or unscaled immediate. > > So, before applying the patch addresses with constant index were > 'improved' by replacing the constant node with a constant load and > relying on the use of register_offset addressing mode to do the actual > memory operation. The result is code like this: > > movz x3, #0xc # constant load of offset value > movk x3, #0x0, lsl #16 > ldr w1 [x2, x3] # (1) load via register_offset addressing > > The patch tries instead to transform the node to use either scaled or > unscaled immediate addressing resulting, respectively, in code like this: > > ldr w1, [x2,#12] # (2) load via scaled immediate addressing > > or (let's assume we had a negative offset mandating an unscaled load) > > ldr w1, [x2, #-12] # (3) load via unscaled immediate addressing > > There are two related reasons why this has been done in the Generate > phase rather than in the AddressLowering phase. I present them both in > turn below in order to pose some questions about why AddressLowering is > currently done as is and to suggest what might be needed to fix it. > > I have also include a critique of the way a derived LIRKind is computed > for the AddressValue returned by method generate(). I am unclear why it > is currently being computed as is and also unclear what would be an > appropriate derived value when immediates are encoded. Advice or > comments regarding the patch and the following critique would be very > welcome. > > Scaling depends on the transfer size > ------------------------------------ > > The first problem is that for scaled memory addressing the decision as > to whether or not a given constant index can be embedded as an immediate > constant in the address node depends upon how the address is used by one > or more memory ops. > > In code example (2) which uses scaled addressing above the load > instruction is transferring a 32 bit datum (as indicated in the assembly > code by the target register being named w1). The load address is the 64 > bit value in r1 (as indicated in the assembly code by the base register > being named x1) plus constant offset 12. > > A scaled immediate memory op can embed a 12 bit unsigned displacement. > However, the unit size for the embedded value is determined by the size > of the accessed datum. So, for a 32 bit load/store the set of offsets > which are valid is {4, 8, ... 4 * (2^12 - 1)}. For a byte load the set > of valid offsets is {1, 2, ... (2^12-1)}. > > Obviously, as the name clearly indicates, there is no dependency on > transfer size when using unscaled addressing. Memory ops employing this > latter addressing may embed any signed 9-bit displacement which is > always counted in a unit size of bytes. So, translation to use unscaled > addressing in the AddressLowering phase doesn't present any great > problem. However, generating the best code requires implementing both modes. > > The upshot is that in order to determine whether a constant index can be > replaced by an immediate node the lowering code needs to investigate > usages of the address node and establish that all usages employ a unique > transfer size. > > As you can see in the pull request, the patch includes a method > getUsageSize() which does that job. It traverses all usages and returns > either a single platform kind which defines a transfer size common to > all usages or null if no such unique common kind exists. This leads to > the second problem. (n.b. I have finessed Prefetch usages for now > because the current AArch64 Graal does not generate code for prefetch. > That will need fixing when it is implemented). > > Identification of the platform kind requires a generator > -------------------------------------------------------- > > The above requirement explains why the lowering code is implemented as > part of the Generate phase instead of in the AddressLowering phase. > Identifying the PlatformKind associated with a specific usage of the > AddressNode requires translating the stamp of each usage to an LIRKind. > That mandates availability of a suitable instance of LIRKindTool > (actually an AArch64LIRKindTool) which parameterizes the call to > getUsageSize(). The KindTool must be obtained from the > AArch64LIRGenerator tool which is obtained form the NodeLIRBuilderTool > passed to the AArch64AddressNode generate() method. > > I don't doubt that here is some sneaky way of ensuring that the > AArch64AddressLowering instance obtains access to an AArch64LIRGenerator > (and, thence, an AArch64LIRKindTool) behind the scenes. However, > implementing a solution like that does not really seem to me to be the > correct solution. There is an assumption in the current code that > address lowering can be done prior to the Generate phase without needing > to identify whatever transfer datum and/or transfer size is at stake > when the address is being used. That's a broken assumption and I would > prefer to fix it. > > One solution would be to have the generic code precompute the common > usage LIRKind and pass it to the implementation class which extends > AddressLowering. Alternatively, the abstract parent class could provide > a convenience method allowing a suitable PlatformKind to be computed. > Either way this means that the parent needs to know about the Arch and > know how to obtain an arch-specific KindTool. I'm happy to look into > proposing a solution along these lines but I'd like to canvas here for > comments before doing so. > > Another alternative would be to perform address lowering at a later > stage, perhaps in the back end even. This would perhaps require doing > some of the transforms done in e.g. AMD64AddressLowering as generic > transforms and having a generic AddressNode which allowed for a > non-constant index and/or constant displacement. I'm also happy to > consider how this might work but I'd probably need more advice about how > to go about this. > > > The LIRKind of the resulting AddressValue -- is it correct? > ----------------------------------------------------------- > > The patch in the pull request attempts to follow the logic of the > preceding code in deriving an LIRKind for whatever AddressNode it > constructs, whether using register offset or immediate addressing. > However, I am not sure what the original logic is. > > In the original code for AArch64AddressNode.generate() the case where > the either base or index was null is treated by setting, respectively, > baseValue or indexValue to Value.ILLEGAL. Later in that original code > this implies that indexReference is also set to Value.ILLEGAL. The > LIRKind for the final resulting AArch64AddressValue is computed by executing > > LIRKind kind = LIRKind.combineDerived(tool.getLIRKind(stamp()), > baseReference, indexReference); > > So, when base is, say, a register and index is null this represents a > direct reference through a register with no offset. I would have > expected that in this circumstance there was some coherent way of > deriving the LIRKind of the address from the LIRKind associated with > base. However, because index is null, so indexValue is Value.ILLEGAL and > hence indexReference is also Value.ILLEGAL. combineDerived handles this > case by returning an unknown reference derived from the stamp(). By > contrast, if indexReference was null then combineDerived would compute > the combined reference by calling makeDerivedReference(base). > > My patch follows this code by starting off with indexValue = null then > resetting it to Value.ILLEGAL either if it is null or if it is possible > to intervene and replace a constant index with a displacement. > Otherwise, when we have a non-null index, indexValue is computed as > before by executing > > indexValue = tool.asAllocatable(gen.operand(index)); > > I have also preserved the original special case processing for > AddressingMode.IMMEDIATE_UNSCALED where the indexReference is derived by > executing > > indexReference = LIRKind.derivedBaseFromValue(indexValue); > > although I'll note that in cases where that addressing mode is > introduced by replacing a constant index with an unscaled displacement > indexValue will be Value.ILLEGAL and hence the indexReference will be > returned as Value.ILLEGAL which seems to negate the purpose of that > special case handling. > > I am suspicious that all of this computation seems to be rather > redundant anyway. At the point of use of an Address to encode a Load or > Store (or possibly a Prefetch) the LIRKind of the address appears to be > ignored and instead the LIRKind of the transfer datum is used to > generate the load. Is this computation of the derived actually achieving > anything important? > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From jaroslav.tulach at oracle.com Wed Mar 1 07:16:02 2017 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Wed, 01 Mar 2017 08:16:02 +0100 Subject: Where is the Truffle Javadoc? Message-ID: <2804092.fsOzi9VaU0@logoutik> Hi. I'd like to announce that after a heroic teamwork we migrated the Truffle Javadoc to more appropriate location: http://graalvm.github.io/truffle In addition to that (and thanks to enormous work of mlvdv) the primary entry point to the Javadoc is a set of Truffle Tutorials. So far we focused mostly on the "embedding" one, but we hope you find all the tutorials useful. Should you have an idea how to improve them, please speak up or send a pull request. We'd like http://graalvm.github.io/truffle to become the ultimate source of information for all kinds of Java developers using Truffle APIs. -jt From jaroslav.tulach at oracle.com Wed Mar 1 13:08:26 2017 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Wed, 01 Mar 2017 14:08:26 +0100 Subject: Contributing to the tutorial was: Where is the Truffle Javadoc? In-Reply-To: <2804092.fsOzi9VaU0@logoutik> References: <2804092.fsOzi9VaU0@logoutik> Message-ID: <2582041.gl2rldcRaV@pracovni> On st?eda 1. b?ezna 2017 8:16:02 CET Jaroslav Tulach wrote: > Hi. > I'd like to announce that after a heroic teamwork we migrated the Truffle > Javadoc to more appropriate location: http://graalvm.github.io/truffle > > In addition to that (and thanks to enormous work of mlvdv) the primary entry > point to the Javadoc is a set of Truffle Tutorials. So far we focused > mostly on the "embedding" one, but we hope you find all the tutorials > useful. > > Should you have an idea how to improve them, please speak up or send a pull > request. We'd like http://graalvm.github.io/truffle to become the ultimate > source of information for all kinds of Java developers using Truffle APIs. Hello again, one of the questions that I have received is: Which repo should these PR be submitted to? We are doing as much as we can to keep the documentation (e.g. the tutorial) as close to the code and classical Javadoc as possible. As such you can find the tutorial in the Truffle repository: https://github.com/graalvm/truffle/tree/ master/truffle/com.oracle.truffle.tutorial/src/com/oracle/truffle/tutorial The com.oracle.truffle.tutorial module contains all the prose sections and it often uses {@codesnippet} to reference [real world code samples](https:// github.com/graalvm/truffle/blob/master/truffle/com.oracle.truffle.tutorial/src/com/ oracle/truffle/tutorial/embedding/package-info.java#L161) to make sure they [compile and run](https://github.com/graalvm/truffle/blob/master/truffle/ com.oracle.truffle.tck/src/com/oracle/truffle/tck/impl/ PolyglotEngineWithJavaScript.java#L69) with our existing implementation. Right now most of our samples deal only with JavaScript, but we'd like to expand it to Ruby and FastR - just we need some help from experts knowing those languages better than the Truffle team does. -jt From adinn at redhat.com Wed Mar 1 16:44:08 2017 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 1 Mar 2017 16:44:08 +0000 Subject: RFR: AArch64: Implementing address lowering to make use of immediate address mode In-Reply-To: <58B61837.60107@oracle.com> References: <206f2ccf-7e37-1b7b-3f30-7b319ddb6534@redhat.com> <58B61837.60107@oracle.com> Message-ID: <68ee82f2-c230-76de-b6bc-88ada8a73e85@redhat.com> Hi Tom, On 01/03/17 00:39, Tom Rodriguez wrote: > There's nothing about the AddressLoweringPhase that says the mapping of > old the OffsetAddressNode to machine dependent address mode must be one > to one. You are free to examine the usages and generate a distinct > address node for each use. GVN will common any duplicates back > together. You still will need to select the right forms for the backend > so it doesn't address all the problems you mention. Thanks very much for replying. I'm not quite sure I follow what you are saying but let me try to confirm that I am on the right track. I do understand that each usage of some given OffsetAddress can be substituted /per usage/ by an appropriate AArch64AddressNode without fear of introducing unnecessary replicas. The thrust of your comment seems to be that my current patch doesn't actually need to detect a single, unique LIRKind for all usages in order to be able to embed a constant index as displacement. It could instead traverse all usages and, where possible, replace the OffsetAddress referenced from the usage with a lowered AddressNode employing a displacement constructed according to the LIRKind of that usage. Is that what you are suggesting? If so then I agree that I might perhaps be able tweak the patch to do this. However, that's really somewhat incidental to the concerns I originally raised, perhaps even providing an a fortiori argument for addressing them. The AddressLowering phase is given an AddressNode to lower, a node which may be shared by multiple usages. It is not given a usage (i.e. a node using the AddressNode) and asked whether it wants to provide a lowered address node specific to that usage. So, the problem remains that the lowering model AddressLowering has adopted is based on a misguided notion that lowering can be scheduled per AddressNode without reference to usage. I really want to try to fix the model not the current patch. If your point is that AddressLowering ought, perhaps, to be rewritten to operate by considering each usage in turn then that would indeed be a better model. Apologies if I am barking up the wrong tree entirely here and have not grasped what you are getting at. Of course, m comments about the need to have access to the usage kind (and, hence, to a KindTool) and my failure to understand how a derived LIRKind should be computed for any lowered AddressNode also still stand in the hope of some comment or explanation which would, of course, be gratefully received. regards, Andrew Dinn ----------- > Andrew Dinn wrote: >> I have patched (a slightly out of date version of) Graal to allow >> AArch64 to make use of scaled and unscaled immediate addressing. This >> generates much better code but the implementation is 'wrong' in several >> important respects. A pull request including the change is available here >> >> https://github.com/graalvm/graal-core/pull/258 >> >> I have no wish for this change to be included as is - I posted it merely >> to enable discussion of what is really needed. >> >> The patch deliberately bypasses the normal AddressLowering phase (I'll >> explain why in a second). Instead it intercepts translation of addresses >> during the generate phase. Basically, it attempts to improve addresses >> initially generated as an OffsetAddress (i.e. supplied with 2 Values, >> base and index) when the index is an integer constant whcih can be >> embedded as an immediate displacement (I guess it ought to handle the >> reverse case where base is a constant and index a general Value but >> nothing appears to be generating addresses with constants in that >> order). It does so by 'nulling' the index saving the constant as a >> displacement and resetting the addressing mode from register offset to >> scaled or unscaled immediate. >> >> So, before applying the patch addresses with constant index were >> 'improved' by replacing the constant node with a constant load and >> relying on the use of register_offset addressing mode to do the actual >> memory operation. The result is code like this: >> >> movz x3, #0xc # constant load of offset value >> movk x3, #0x0, lsl #16 >> ldr w1 [x2, x3] # (1) load via register_offset addressing >> >> The patch tries instead to transform the node to use either scaled or >> unscaled immediate addressing resulting, respectively, in code like this: >> >> ldr w1, [x2,#12] # (2) load via scaled immediate addressing >> >> or (let's assume we had a negative offset mandating an unscaled load) >> >> ldr w1, [x2, #-12] # (3) load via unscaled immediate addressing >> >> There are two related reasons why this has been done in the Generate >> phase rather than in the AddressLowering phase. I present them both in >> turn below in order to pose some questions about why AddressLowering is >> currently done as is and to suggest what might be needed to fix it. >> >> I have also include a critique of the way a derived LIRKind is computed >> for the AddressValue returned by method generate(). I am unclear why it >> is currently being computed as is and also unclear what would be an >> appropriate derived value when immediates are encoded. Advice or >> comments regarding the patch and the following critique would be very >> welcome. >> >> Scaling depends on the transfer size >> ------------------------------------ >> >> The first problem is that for scaled memory addressing the decision as >> to whether or not a given constant index can be embedded as an immediate >> constant in the address node depends upon how the address is used by one >> or more memory ops. >> >> In code example (2) which uses scaled addressing above the load >> instruction is transferring a 32 bit datum (as indicated in the assembly >> code by the target register being named w1). The load address is the 64 >> bit value in r1 (as indicated in the assembly code by the base register >> being named x1) plus constant offset 12. >> >> A scaled immediate memory op can embed a 12 bit unsigned displacement. >> However, the unit size for the embedded value is determined by the size >> of the accessed datum. So, for a 32 bit load/store the set of offsets >> which are valid is {4, 8, ... 4 * (2^12 - 1)}. For a byte load the set >> of valid offsets is {1, 2, ... (2^12-1)}. >> >> Obviously, as the name clearly indicates, there is no dependency on >> transfer size when using unscaled addressing. Memory ops employing this >> latter addressing may embed any signed 9-bit displacement which is >> always counted in a unit size of bytes. So, translation to use unscaled >> addressing in the AddressLowering phase doesn't present any great >> problem. However, generating the best code requires implementing both >> modes. >> >> The upshot is that in order to determine whether a constant index can be >> replaced by an immediate node the lowering code needs to investigate >> usages of the address node and establish that all usages employ a unique >> transfer size. >> >> As you can see in the pull request, the patch includes a method >> getUsageSize() which does that job. It traverses all usages and returns >> either a single platform kind which defines a transfer size common to >> all usages or null if no such unique common kind exists. This leads to >> the second problem. (n.b. I have finessed Prefetch usages for now >> because the current AArch64 Graal does not generate code for prefetch. >> That will need fixing when it is implemented). >> >> Identification of the platform kind requires a generator >> -------------------------------------------------------- >> >> The above requirement explains why the lowering code is implemented as >> part of the Generate phase instead of in the AddressLowering phase. >> Identifying the PlatformKind associated with a specific usage of the >> AddressNode requires translating the stamp of each usage to an LIRKind. >> That mandates availability of a suitable instance of LIRKindTool >> (actually an AArch64LIRKindTool) which parameterizes the call to >> getUsageSize(). The KindTool must be obtained from the >> AArch64LIRGenerator tool which is obtained form the NodeLIRBuilderTool >> passed to the AArch64AddressNode generate() method. >> >> I don't doubt that here is some sneaky way of ensuring that the >> AArch64AddressLowering instance obtains access to an AArch64LIRGenerator >> (and, thence, an AArch64LIRKindTool) behind the scenes. However, >> implementing a solution like that does not really seem to me to be the >> correct solution. There is an assumption in the current code that >> address lowering can be done prior to the Generate phase without needing >> to identify whatever transfer datum and/or transfer size is at stake >> when the address is being used. That's a broken assumption and I would >> prefer to fix it. >> >> One solution would be to have the generic code precompute the common >> usage LIRKind and pass it to the implementation class which extends >> AddressLowering. Alternatively, the abstract parent class could provide >> a convenience method allowing a suitable PlatformKind to be computed. >> Either way this means that the parent needs to know about the Arch and >> know how to obtain an arch-specific KindTool. I'm happy to look into >> proposing a solution along these lines but I'd like to canvas here for >> comments before doing so. >> >> Another alternative would be to perform address lowering at a later >> stage, perhaps in the back end even. This would perhaps require doing >> some of the transforms done in e.g. AMD64AddressLowering as generic >> transforms and having a generic AddressNode which allowed for a >> non-constant index and/or constant displacement. I'm also happy to >> consider how this might work but I'd probably need more advice about how >> to go about this. >> >> >> The LIRKind of the resulting AddressValue -- is it correct? >> ----------------------------------------------------------- >> >> The patch in the pull request attempts to follow the logic of the >> preceding code in deriving an LIRKind for whatever AddressNode it >> constructs, whether using register offset or immediate addressing. >> However, I am not sure what the original logic is. >> >> In the original code for AArch64AddressNode.generate() the case where >> the either base or index was null is treated by setting, respectively, >> baseValue or indexValue to Value.ILLEGAL. Later in that original code >> this implies that indexReference is also set to Value.ILLEGAL. The >> LIRKind for the final resulting AArch64AddressValue is computed by >> executing >> >> LIRKind kind = LIRKind.combineDerived(tool.getLIRKind(stamp()), >> baseReference, indexReference); >> >> So, when base is, say, a register and index is null this represents a >> direct reference through a register with no offset. I would have >> expected that in this circumstance there was some coherent way of >> deriving the LIRKind of the address from the LIRKind associated with >> base. However, because index is null, so indexValue is Value.ILLEGAL and >> hence indexReference is also Value.ILLEGAL. combineDerived handles this >> case by returning an unknown reference derived from the stamp(). By >> contrast, if indexReference was null then combineDerived would compute >> the combined reference by calling makeDerivedReference(base). >> >> My patch follows this code by starting off with indexValue = null then >> resetting it to Value.ILLEGAL either if it is null or if it is possible >> to intervene and replace a constant index with a displacement. >> Otherwise, when we have a non-null index, indexValue is computed as >> before by executing >> >> indexValue = tool.asAllocatable(gen.operand(index)); >> >> I have also preserved the original special case processing for >> AddressingMode.IMMEDIATE_UNSCALED where the indexReference is derived by >> executing >> >> indexReference = LIRKind.derivedBaseFromValue(indexValue); >> >> although I'll note that in cases where that addressing mode is >> introduced by replacing a constant index with an unscaled displacement >> indexValue will be Value.ILLEGAL and hence the indexReference will be >> returned as Value.ILLEGAL which seems to negate the purpose of that >> special case handling. >> >> I am suspicious that all of this computation seems to be rather >> redundant anyway. At the point of use of an Address to encode a Load or >> Store (or possibly a Prefetch) the LIRKind of the address appears to be >> ignored and instead the LIRKind of the transfer datum is used to >> generate the load. Is this computation of the derived actually achieving >> anything important? >> >> regards, >> >> >> Andrew Dinn >> ----------- >> Senior Principal Software Engineer >> Red Hat UK Ltd >> Registered in England and Wales under Company Registration No. 03798903 >> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From deepali_patel at persistent.com Thu Mar 2 12:17:09 2017 From: deepali_patel at persistent.com (Deepali Patel) Date: Thu, 2 Mar 2017 12:17:09 +0000 Subject: Error while building JVMCI enabled JDK8 on Power References: <6B778C59-F1F2-4973-AD86-15C27C9EB335@oracle.com> Message-ID: Hello Doug and Gilles, I have updated the arch to ppc64le. Next, I see errors for missing c1_globals_ppc.hpp file. The src/cpu/x86/vm directory contains this file for x86 and also contains many other files for C1. Looks like I will need all these files for PPC as well. However the corresponding directory - src/cpu/ppc/vm does not have these C1 files, although it does have 2 files for C2. Is there any specific reason due to which C1 implementation is not available for ppc or it is just unimplemented currently. Please advise. Regards Deepali -----Original Message----- From: Deepali Patel Sent: Tuesday, February 28, 2017 6:18 PM To: 'Doug Simon' Cc: Gilles Duboscq; graal-dev at openjdk.java.net Subject: RE: Error while building JVMCI enabled JDK8 on Power Hi Doug, Thanks for helpful response. I have copied jvmci/jdk.vm.ci.amd64 and jvmci/jdk.vm.ci.hotspot.amd64 to create jvmci/jdk.vm.ci.ppc64 and jvmci/jdk.vm.ci.hotspot.ppc64 (as suggested by Gilles) respectively. I have modified the source code files to reflect ppc64 instead of amd64 in these folders. Then I realized that graal-jvmci-8/mx.jvmci/suite.py also needs to be updated to incorporate these new folders. I have also added ppc64le as the supported arch for the Distributions in graal-jvmci-8/mx.jvmci/suite.py. By default, the ppc64 is set as arch for LE versions as well, however this leads to following error. The jdk source code has jvm.cfg file under ppc64le folder: mx --java-home /usr/lib/jvm/java-8-openjdk-ppc64el build None {'ppc64': {'path': 'build/product/linux/ppc64/server/jvm.tar'}, 'amd64': {'path': 'build/product/linux/amd64/server/jvm.tar'}, 'sparcv9': {'path': 'build/product/linux/sparcv9/server/jvm.tar'}} Creating /home/deepali/Graal/graal-jvmci-8/jdk1.8.0_121/product from /usr/lib/jvm/java-8-openjdk-ppc64el /home/deepali/Graal/graal-jvmci-8/jdk1.8.0_121/product/jre/lib/ppc64/jvm.cfg does not exist Thus I think I need to update the arch to ppc64le in the makefiles. Another thing that I noticed is " WARNING: hsdis with flavor 'None' not supported on this plattform or architecture". So looks like I will need to port hsdis as well because it is not available for ppc at https://lafo.ssw.uni-linz.ac.at/pub/hsdis/. Regards Deepali -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Friday, February 24, 2017 2:48 PM To: Deepali Patel Cc: Gilles Duboscq; graal-dev at openjdk.java.net Subject: Re: Error while building JVMCI enabled JDK8 on Power > On 24 Feb 2017, at 09:20, Deepali Patel wrote: > > Thanks Doug and Gilles for quick response. > > Could you please throw some more light on the parts of code(folders, files etc) that will need to be updated/modified to get this working on PPC. Would we need assembly code as well? If so, could you please point me to the corresponding x86 files for reference. dsimon at kurz-3 ~/g/graal-jvmci-8> find src | grep jvmci | grep x86 src/cpu/x86/vm/jvmci_globals_x86.hpp src/cpu/x86/vm/jvmciCodeInstaller_x86.cpp dsimon at kurz-3 ~/g/graal-jvmci-8> find src | grep jvmci | grep sparc src/cpu/sparc/vm/jvmci_globals_sparc.hpp src/cpu/sparc/vm/jvmciCodeInstaller_sparc.cpp dsimon at kurz-3 ~/g/graal-core> ls -d graal/*sparc* graal/org.graalvm.compiler.asm.sparc graal/org.graalvm.compiler.core.sparc.test graal/org.graalvm.compiler.replacements.sparc graal/org.graalvm.compiler.asm.sparc.test graal/org.graalvm.compiler.hotspot.sparc graal/org.graalvm.compiler.truffle.hotspot.sparc graal/org.graalvm.compiler.core.sparc graal/org.graalvm.compiler.lir.sparc dsimon at kurz-3 ~/g/graal-core> ls -d graal/*amd64* graal/org.graalvm.compiler.asm.amd64 graal/org.graalvm.compiler.core.amd64.test graal/org.graalvm.compiler.lir.amd64 graal/org.graalvm.compiler.asm.amd64.test graal/org.graalvm.compiler.hotspot.amd64 graal/org.graalvm.compiler.replacements.amd64 graal/org.graalvm.compiler.core.amd64 graal/org.graalvm.compiler.hotspot.amd64.test graal/org.graalvm.compiler.truffle.hotspot.amd64 Hope that helps, -Doug > -----Original Message----- > From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf > Of Gilles Duboscq > Sent: Thursday, February 23, 2017 5:02 PM > To: graal-dev at openjdk.java.net > Subject: Re: Error while building JVMCI enabled JDK8 on Power > > You will also need to implement the Java side of things. > See for example the sources in jvmci/jdk.vm.ci.amd64 and jvmci/jdk.vm.ci.hotspot.amd64. > > Gilles > > On 23/02/17 11:26, Doug Simon wrote: >> Hi Deepali, >> >> This is an interesting but non-trivial project I suspect. You will need to look at all the machine specific JVMCI files and create corresponding *_ppc.[hpp|cpp] files. The existing jvmciGlobals_ppc.hpp needs to be renamed to jvmci_globals_ppc.hpp (as you observed) and completed as part of this. >> >> -Doug >> >>> On 23 Feb 2017, at 10:41, Deepali Patel wrote: >>> >>> Hello Team, >>> >>> I am trying to build Graal core on Power. >>> >>> >>> 1. I have updated mx.py to allow build on Power: >>> ----------------- >>> diff --git a/mx.py b/mx.py >>> index 172609d..de932f6 100755 >>> --- a/mx.py >>> +++ b/mx.py >>> @@ -7369,6 +7369,8 @@ def get_arch(): >>> except OSError: >>> # sysctl is not available >>> pass >>> + if machine == 'ppc64le' and get_os() == 'linux': >>> + return 'ppc64le' >>> abort('unknown or unsupported architecture: os=' + get_os() + ', >>> machine=' + machine) >>> >>> mx_subst.results_substitutions.register_no_arg('arch', get_arch) >>> ------------------------------ >>> >>> >>> 2. Next I am trying to build building JVMCI enabled JDK8. However, I see following error: >>> >>> Generating precompiled header precompiled.hpp.gch >>> >>> In file included from /pathto/allocation.hpp:28:0, >>> >>> from /pathto/iterator.hpp:28, >>> >>> from /pathto/genOopClosures.hpp:28, >>> >>> from /pathto/klass.hpp:28, >>> >>> from /pathto/handles.hpp:28, >>> >>> from /pathto/universe.hpp:28, >>> >>> from /pathto/oopRecorder.hpp:28, >>> >>> from /pathto/codeBuffer.hpp:28, >>> >>> from /pathto/assembler.hpp:28, >>> >>> from /pathto/precompiled.hpp:29: >>> >>> /pathto/globals.hpp:143:34: fatal error: jvmci_globals_ppc.hpp: No >>> such file or directory >>> >>> compilation terminated. >>> >>> /pathto/vm.make:322: recipe for target 'precompiled.hpp.gch' failed >>> >>> make[4]: Leaving directory '/pathto/linux_ppc64_compiler2/product' >>> >>> make[4]: *** [precompiled.hpp.gch] Error 1 >>> >>> /pathto/top.make:119: recipe for target 'the_vm' failed >>> >>> make[3]: Leaving directory '/pathto/product' >>> >>> /pathto/make/linux/Makefile:303: recipe for target 'product' failed >>> >>> make[2]: Leaving directory '/pathto/graal-jvmci-8/build/linux' >>> >>> Makefile:231: recipe for target 'generic_build2' failed >>> >>> make[1]: Leaving directory '/pathtoGraal/graal-jvmci-8/make' >>> >>> make[3]: *** [the_vm] Error 2 >>> >>> make[2]: *** [product] Error 2 >>> >>> make[1]: *** [generic_build2] Error 2 >>> >>> Makefile:182: recipe for target 'product' failed >>> >>> make: *** [product] Error 2 >>> >>> make: Leaving directory '/pathto/graal-jvmci-8/make' >>> >>> Building HotSpot[product, server] failed >>> >>> 1 build tasks failed >>> >>> >>> >>> 3. I dont see jvmci_globals_ppc.hpp in the src tree. But there is another file with name jvmciGlobals_ppc.hpp available in the src tree. I tried to use jvmciGlobals_ppc.hpp, but I get following errors: >>> >>> /pathto/graal-jvmci-8/src/cpu/ppc/vm/jvmciGlobals_ppc.hpp:35:2: >>> error: #error Unimplemented >>> >>> #error Unimplemented >>> >>> ^ >>> >>> /pathto/graal-jvmci-8/make/linux/makefiles/vm.make:322: recipe for >>> target 'precompiled.hpp.gch' failed >>> >>> Please advise if I am missing on something here. >>> >>> Regards >>> Deepali >>> >>> >>> >>> DISCLAIMER >>> ========== >>> This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. >>> >> > > DISCLAIMER > ========== > This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. > DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. From russpowers at gmail.com Thu Mar 2 13:33:31 2017 From: russpowers at gmail.com (Russ Powers) Date: Thu, 2 Mar 2017 05:33:31 -0800 Subject: Problem with JVMCI on Cygwin Message-ID: Hello, I've managed to build JVMCI on Cygwin, and the jdk1.8.0_121\product\jre\bin\server directory contains the built jvm.dll and jvm.pdb. However, when I try using mx on graal-core (with the proper JAVA_HOME set), it gives me this error: The VM does not support the minimum JVMCI API version required by Graal. Cannot read JVMCI version from java.vm.version property: 25.71-b01-internal. Set the JVMCI_VERSION_CHECK environment variable to "ignore" to suppress this error or to "warn" to emit a warning and continue execution. Currently used Java home directory is c:\proj\graal\tools\graal- jvmci-8\jdk1.8.0_121\product\jre. It looks like the JVMCI info is missing, and when I run ./java -version, it doesn't contain the JVMCI info either. I checked, and it's definitely using the newly built jvm.dll. Is there something else I should be doing here? I'm stumped. Thanks in advance. Russ From gilles.m.duboscq at oracle.com Thu Mar 2 13:59:54 2017 From: gilles.m.duboscq at oracle.com (Gilles Duboscq) Date: Thu, 2 Mar 2017 14:59:54 +0100 Subject: Problem with JVMCI on Cygwin In-Reply-To: References: Message-ID: Hi Russ, When building on Windows, it's probably better not to use Cygwin. When running on cygwin, mx tries to use some kind of hybrid mode where we run on cygwin (unix-ish) but target Windows for the JVMCI build. That's very fragile/hacky. Could you try running in a normal windows environment (make sure you use Windows python, not cygwin python)? Unfortunately we have not been testing on windows for a long time so it's likely that windows support has bit-rotten in both mx and graal-jvmci-8. Gilles On 02/03/17 14:33, Russ Powers wrote: > Hello, > > I've managed to build JVMCI on Cygwin, and the > jdk1.8.0_121\product\jre\bin\server > directory contains the built jvm.dll and jvm.pdb. However, when I try > using mx on graal-core (with the proper JAVA_HOME set), it gives me this > error: > > The VM does not support the minimum JVMCI API version required by Graal. > Cannot read JVMCI version from java.vm.version property: 25.71-b01-internal. > Set the JVMCI_VERSION_CHECK environment variable to "ignore" to suppress > this error or to "warn" to emit a warning and continue execution. > Currently used Java home directory is c:\proj\graal\tools\graal- > jvmci-8\jdk1.8.0_121\product\jre. > > It looks like the JVMCI info is missing, and when I run ./java -version, it > doesn't contain the JVMCI info either. I checked, and it's definitely > using the newly built jvm.dll. Is there something else I should be doing > here? I'm stumped. Thanks in advance. > > Russ > From cthalinger at twitter.com Thu Mar 2 17:20:03 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Thu, 2 Mar 2017 07:20:03 -1000 Subject: Error while building JVMCI enabled JDK8 on Power In-Reply-To: References: <6B778C59-F1F2-4973-AD86-15C27C9EB335@oracle.com> Message-ID: You should talk to some of the SAP people. Volker, has anyone at SAP thought or even done some work on JVMCI for PPC? > On Mar 2, 2017, at 2:17 AM, Deepali Patel wrote: > > Hello Doug and Gilles, > > I have updated the arch to ppc64le. > > Next, I see errors for missing c1_globals_ppc.hpp file. The src/cpu/x86/vm directory contains this file for x86 and also contains many other files for C1. Looks like I will need all these files for PPC as well. However the corresponding directory - src/cpu/ppc/vm does not have these C1 files, although it does have 2 files for C2. Is there any specific reason due to which C1 implementation is not available for ppc or it is just unimplemented currently. Please advise. > > Regards > Deepali > -----Original Message----- > From: Deepali Patel > Sent: Tuesday, February 28, 2017 6:18 PM > To: 'Doug Simon' > Cc: Gilles Duboscq; graal-dev at openjdk.java.net > Subject: RE: Error while building JVMCI enabled JDK8 on Power > > Hi Doug, > > Thanks for helpful response. > > I have copied jvmci/jdk.vm.ci.amd64 and jvmci/jdk.vm.ci.hotspot.amd64 to create jvmci/jdk.vm.ci.ppc64 and jvmci/jdk.vm.ci.hotspot.ppc64 (as suggested by Gilles) respectively. I have modified the source code files to reflect ppc64 instead of amd64 in these folders. > > Then I realized that graal-jvmci-8/mx.jvmci/suite.py also needs to be updated to incorporate these new folders. I have also added ppc64le as the supported arch for the Distributions in graal-jvmci-8/mx.jvmci/suite.py. > > By default, the ppc64 is set as arch for LE versions as well, however this leads to following error. The jdk source code has jvm.cfg file under ppc64le folder: > mx --java-home /usr/lib/jvm/java-8-openjdk-ppc64el build > None > {'ppc64': {'path': 'build/product/linux/ppc64/server/jvm.tar'}, 'amd64': {'path': 'build/product/linux/amd64/server/jvm.tar'}, 'sparcv9': {'path': 'build/product/linux/sparcv9/server/jvm.tar'}} > Creating /home/deepali/Graal/graal-jvmci-8/jdk1.8.0_121/product from /usr/lib/jvm/java-8-openjdk-ppc64el > /home/deepali/Graal/graal-jvmci-8/jdk1.8.0_121/product/jre/lib/ppc64/jvm.cfg does not exist > > Thus I think I need to update the arch to ppc64le in the makefiles. > > Another thing that I noticed is " WARNING: hsdis with flavor 'None' not supported on this plattform or architecture". So looks like I will need to port hsdis as well because it is not available for ppc at https://lafo.ssw.uni-linz.ac.at/pub/hsdis/. > > Regards > Deepali > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Friday, February 24, 2017 2:48 PM > To: Deepali Patel > Cc: Gilles Duboscq; graal-dev at openjdk.java.net > Subject: Re: Error while building JVMCI enabled JDK8 on Power > > >> On 24 Feb 2017, at 09:20, Deepali Patel wrote: >> >> Thanks Doug and Gilles for quick response. >> >> Could you please throw some more light on the parts of code(folders, files etc) that will need to be updated/modified to get this working on PPC. Would we need assembly code as well? If so, could you please point me to the corresponding x86 files for reference. > > dsimon at kurz-3 ~/g/graal-jvmci-8> find src | grep jvmci | grep x86 src/cpu/x86/vm/jvmci_globals_x86.hpp > src/cpu/x86/vm/jvmciCodeInstaller_x86.cpp > dsimon at kurz-3 ~/g/graal-jvmci-8> find src | grep jvmci | grep sparc src/cpu/sparc/vm/jvmci_globals_sparc.hpp > src/cpu/sparc/vm/jvmciCodeInstaller_sparc.cpp > > dsimon at kurz-3 ~/g/graal-core> ls -d graal/*sparc* > graal/org.graalvm.compiler.asm.sparc graal/org.graalvm.compiler.core.sparc.test graal/org.graalvm.compiler.replacements.sparc > graal/org.graalvm.compiler.asm.sparc.test graal/org.graalvm.compiler.hotspot.sparc graal/org.graalvm.compiler.truffle.hotspot.sparc > graal/org.graalvm.compiler.core.sparc graal/org.graalvm.compiler.lir.sparc > dsimon at kurz-3 ~/g/graal-core> ls -d graal/*amd64* > graal/org.graalvm.compiler.asm.amd64 graal/org.graalvm.compiler.core.amd64.test graal/org.graalvm.compiler.lir.amd64 > graal/org.graalvm.compiler.asm.amd64.test graal/org.graalvm.compiler.hotspot.amd64 graal/org.graalvm.compiler.replacements.amd64 > graal/org.graalvm.compiler.core.amd64 graal/org.graalvm.compiler.hotspot.amd64.test graal/org.graalvm.compiler.truffle.hotspot.amd64 > > Hope that helps, > > -Doug > >> -----Original Message----- >> From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf >> Of Gilles Duboscq >> Sent: Thursday, February 23, 2017 5:02 PM >> To: graal-dev at openjdk.java.net >> Subject: Re: Error while building JVMCI enabled JDK8 on Power >> >> You will also need to implement the Java side of things. >> See for example the sources in jvmci/jdk.vm.ci.amd64 and jvmci/jdk.vm.ci.hotspot.amd64. >> >> Gilles >> >> On 23/02/17 11:26, Doug Simon wrote: >>> Hi Deepali, >>> >>> This is an interesting but non-trivial project I suspect. You will need to look at all the machine specific JVMCI files and create corresponding *_ppc.[hpp|cpp] files. The existing jvmciGlobals_ppc.hpp needs to be renamed to jvmci_globals_ppc.hpp (as you observed) and completed as part of this. >>> >>> -Doug >>> >>>> On 23 Feb 2017, at 10:41, Deepali Patel wrote: >>>> >>>> Hello Team, >>>> >>>> I am trying to build Graal core on Power. >>>> >>>> >>>> 1. I have updated mx.py to allow build on Power: >>>> ----------------- >>>> diff --git a/mx.py b/mx.py >>>> index 172609d..de932f6 100755 >>>> --- a/mx.py >>>> +++ b/mx.py >>>> @@ -7369,6 +7369,8 @@ def get_arch(): >>>> except OSError: >>>> # sysctl is not available >>>> pass >>>> + if machine == 'ppc64le' and get_os() == 'linux': >>>> + return 'ppc64le' >>>> abort('unknown or unsupported architecture: os=' + get_os() + ', >>>> machine=' + machine) >>>> >>>> mx_subst.results_substitutions.register_no_arg('arch', get_arch) >>>> ------------------------------ >>>> >>>> >>>> 2. Next I am trying to build building JVMCI enabled JDK8. However, I see following error: >>>> >>>> Generating precompiled header precompiled.hpp.gch >>>> >>>> In file included from /pathto/allocation.hpp:28:0, >>>> >>>> from /pathto/iterator.hpp:28, >>>> >>>> from /pathto/genOopClosures.hpp:28, >>>> >>>> from /pathto/klass.hpp:28, >>>> >>>> from /pathto/handles.hpp:28, >>>> >>>> from /pathto/universe.hpp:28, >>>> >>>> from /pathto/oopRecorder.hpp:28, >>>> >>>> from /pathto/codeBuffer.hpp:28, >>>> >>>> from /pathto/assembler.hpp:28, >>>> >>>> from /pathto/precompiled.hpp:29: >>>> >>>> /pathto/globals.hpp:143:34: fatal error: jvmci_globals_ppc.hpp: No >>>> such file or directory >>>> >>>> compilation terminated. >>>> >>>> /pathto/vm.make:322: recipe for target 'precompiled.hpp.gch' failed >>>> >>>> make[4]: Leaving directory '/pathto/linux_ppc64_compiler2/product' >>>> >>>> make[4]: *** [precompiled.hpp.gch] Error 1 >>>> >>>> /pathto/top.make:119: recipe for target 'the_vm' failed >>>> >>>> make[3]: Leaving directory '/pathto/product' >>>> >>>> /pathto/make/linux/Makefile:303: recipe for target 'product' failed >>>> >>>> make[2]: Leaving directory '/pathto/graal-jvmci-8/build/linux' >>>> >>>> Makefile:231: recipe for target 'generic_build2' failed >>>> >>>> make[1]: Leaving directory '/pathtoGraal/graal-jvmci-8/make' >>>> >>>> make[3]: *** [the_vm] Error 2 >>>> >>>> make[2]: *** [product] Error 2 >>>> >>>> make[1]: *** [generic_build2] Error 2 >>>> >>>> Makefile:182: recipe for target 'product' failed >>>> >>>> make: *** [product] Error 2 >>>> >>>> make: Leaving directory '/pathto/graal-jvmci-8/make' >>>> >>>> Building HotSpot[product, server] failed >>>> >>>> 1 build tasks failed >>>> >>>> >>>> >>>> 3. I dont see jvmci_globals_ppc.hpp in the src tree. But there is another file with name jvmciGlobals_ppc.hpp available in the src tree. I tried to use jvmciGlobals_ppc.hpp, but I get following errors: >>>> >>>> /pathto/graal-jvmci-8/src/cpu/ppc/vm/jvmciGlobals_ppc.hpp:35:2: >>>> error: #error Unimplemented >>>> >>>> #error Unimplemented >>>> >>>> ^ >>>> >>>> /pathto/graal-jvmci-8/make/linux/makefiles/vm.make:322: recipe for >>>> target 'precompiled.hpp.gch' failed >>>> >>>> Please advise if I am missing on something here. >>>> >>>> Regards >>>> Deepali >>>> >>>> >>>> >>>> DISCLAIMER >>>> ========== >>>> This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. >>>> >>> >> >> DISCLAIMER >> ========== >> This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. >> > > > DISCLAIMER > ========== > This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. > From volker.simonis at gmail.com Thu Mar 2 17:46:15 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 2 Mar 2017 18:46:15 +0100 Subject: Error while building JVMCI enabled JDK8 on Power In-Reply-To: References: <6B778C59-F1F2-4973-AD86-15C27C9EB335@oracle.com> Message-ID: No, unfortunately not :( We're currently totally overloaded with Java 9 so we won't have time for JVMCI/Graal until after we've released that. Regards, Volker On Thu, Mar 2, 2017 at 6:20 PM, Christian Thalinger wrote: > You should talk to some of the SAP people. Volker, has anyone at SAP thought or even done some work on JVMCI for PPC? > >> On Mar 2, 2017, at 2:17 AM, Deepali Patel wrote: >> >> Hello Doug and Gilles, >> >> I have updated the arch to ppc64le. >> >> Next, I see errors for missing c1_globals_ppc.hpp file. The src/cpu/x86/vm directory contains this file for x86 and also contains many other files for C1. Looks like I will need all these files for PPC as well. However the corresponding directory - src/cpu/ppc/vm does not have these C1 files, although it does have 2 files for C2. Is there any specific reason due to which C1 implementation is not available for ppc or it is just unimplemented currently. Please advise. >> >> Regards >> Deepali >> -----Original Message----- >> From: Deepali Patel >> Sent: Tuesday, February 28, 2017 6:18 PM >> To: 'Doug Simon' >> Cc: Gilles Duboscq; graal-dev at openjdk.java.net >> Subject: RE: Error while building JVMCI enabled JDK8 on Power >> >> Hi Doug, >> >> Thanks for helpful response. >> >> I have copied jvmci/jdk.vm.ci.amd64 and jvmci/jdk.vm.ci.hotspot.amd64 to create jvmci/jdk.vm.ci.ppc64 and jvmci/jdk.vm.ci.hotspot.ppc64 (as suggested by Gilles) respectively. I have modified the source code files to reflect ppc64 instead of amd64 in these folders. >> >> Then I realized that graal-jvmci-8/mx.jvmci/suite.py also needs to be updated to incorporate these new folders. I have also added ppc64le as the supported arch for the Distributions in graal-jvmci-8/mx.jvmci/suite.py. >> >> By default, the ppc64 is set as arch for LE versions as well, however this leads to following error. The jdk source code has jvm.cfg file under ppc64le folder: >> mx --java-home /usr/lib/jvm/java-8-openjdk-ppc64el build >> None >> {'ppc64': {'path': 'build/product/linux/ppc64/server/jvm.tar'}, 'amd64': {'path': 'build/product/linux/amd64/server/jvm.tar'}, 'sparcv9': {'path': 'build/product/linux/sparcv9/server/jvm.tar'}} >> Creating /home/deepali/Graal/graal-jvmci-8/jdk1.8.0_121/product from /usr/lib/jvm/java-8-openjdk-ppc64el >> /home/deepali/Graal/graal-jvmci-8/jdk1.8.0_121/product/jre/lib/ppc64/jvm.cfg does not exist >> >> Thus I think I need to update the arch to ppc64le in the makefiles. >> >> Another thing that I noticed is " WARNING: hsdis with flavor 'None' not supported on this plattform or architecture". So looks like I will need to port hsdis as well because it is not available for ppc at https://lafo.ssw.uni-linz.ac.at/pub/hsdis/. >> >> Regards >> Deepali >> >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Friday, February 24, 2017 2:48 PM >> To: Deepali Patel >> Cc: Gilles Duboscq; graal-dev at openjdk.java.net >> Subject: Re: Error while building JVMCI enabled JDK8 on Power >> >> >>> On 24 Feb 2017, at 09:20, Deepali Patel wrote: >>> >>> Thanks Doug and Gilles for quick response. >>> >>> Could you please throw some more light on the parts of code(folders, files etc) that will need to be updated/modified to get this working on PPC. Would we need assembly code as well? If so, could you please point me to the corresponding x86 files for reference. >> >> dsimon at kurz-3 ~/g/graal-jvmci-8> find src | grep jvmci | grep x86 src/cpu/x86/vm/jvmci_globals_x86.hpp >> src/cpu/x86/vm/jvmciCodeInstaller_x86.cpp >> dsimon at kurz-3 ~/g/graal-jvmci-8> find src | grep jvmci | grep sparc src/cpu/sparc/vm/jvmci_globals_sparc.hpp >> src/cpu/sparc/vm/jvmciCodeInstaller_sparc.cpp >> >> dsimon at kurz-3 ~/g/graal-core> ls -d graal/*sparc* >> graal/org.graalvm.compiler.asm.sparc graal/org.graalvm.compiler.core.sparc.test graal/org.graalvm.compiler.replacements.sparc >> graal/org.graalvm.compiler.asm.sparc.test graal/org.graalvm.compiler.hotspot.sparc graal/org.graalvm.compiler.truffle.hotspot.sparc >> graal/org.graalvm.compiler.core.sparc graal/org.graalvm.compiler.lir.sparc >> dsimon at kurz-3 ~/g/graal-core> ls -d graal/*amd64* >> graal/org.graalvm.compiler.asm.amd64 graal/org.graalvm.compiler.core.amd64.test graal/org.graalvm.compiler.lir.amd64 >> graal/org.graalvm.compiler.asm.amd64.test graal/org.graalvm.compiler.hotspot.amd64 graal/org.graalvm.compiler.replacements.amd64 >> graal/org.graalvm.compiler.core.amd64 graal/org.graalvm.compiler.hotspot.amd64.test graal/org.graalvm.compiler.truffle.hotspot.amd64 >> >> Hope that helps, >> >> -Doug >> >>> -----Original Message----- >>> From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf >>> Of Gilles Duboscq >>> Sent: Thursday, February 23, 2017 5:02 PM >>> To: graal-dev at openjdk.java.net >>> Subject: Re: Error while building JVMCI enabled JDK8 on Power >>> >>> You will also need to implement the Java side of things. >>> See for example the sources in jvmci/jdk.vm.ci.amd64 and jvmci/jdk.vm.ci.hotspot.amd64. >>> >>> Gilles >>> >>> On 23/02/17 11:26, Doug Simon wrote: >>>> Hi Deepali, >>>> >>>> This is an interesting but non-trivial project I suspect. You will need to look at all the machine specific JVMCI files and create corresponding *_ppc.[hpp|cpp] files. The existing jvmciGlobals_ppc.hpp needs to be renamed to jvmci_globals_ppc.hpp (as you observed) and completed as part of this. >>>> >>>> -Doug >>>> >>>>> On 23 Feb 2017, at 10:41, Deepali Patel wrote: >>>>> >>>>> Hello Team, >>>>> >>>>> I am trying to build Graal core on Power. >>>>> >>>>> >>>>> 1. I have updated mx.py to allow build on Power: >>>>> ----------------- >>>>> diff --git a/mx.py b/mx.py >>>>> index 172609d..de932f6 100755 >>>>> --- a/mx.py >>>>> +++ b/mx.py >>>>> @@ -7369,6 +7369,8 @@ def get_arch(): >>>>> except OSError: >>>>> # sysctl is not available >>>>> pass >>>>> + if machine == 'ppc64le' and get_os() == 'linux': >>>>> + return 'ppc64le' >>>>> abort('unknown or unsupported architecture: os=' + get_os() + ', >>>>> machine=' + machine) >>>>> >>>>> mx_subst.results_substitutions.register_no_arg('arch', get_arch) >>>>> ------------------------------ >>>>> >>>>> >>>>> 2. Next I am trying to build building JVMCI enabled JDK8. However, I see following error: >>>>> >>>>> Generating precompiled header precompiled.hpp.gch >>>>> >>>>> In file included from /pathto/allocation.hpp:28:0, >>>>> >>>>> from /pathto/iterator.hpp:28, >>>>> >>>>> from /pathto/genOopClosures.hpp:28, >>>>> >>>>> from /pathto/klass.hpp:28, >>>>> >>>>> from /pathto/handles.hpp:28, >>>>> >>>>> from /pathto/universe.hpp:28, >>>>> >>>>> from /pathto/oopRecorder.hpp:28, >>>>> >>>>> from /pathto/codeBuffer.hpp:28, >>>>> >>>>> from /pathto/assembler.hpp:28, >>>>> >>>>> from /pathto/precompiled.hpp:29: >>>>> >>>>> /pathto/globals.hpp:143:34: fatal error: jvmci_globals_ppc.hpp: No >>>>> such file or directory >>>>> >>>>> compilation terminated. >>>>> >>>>> /pathto/vm.make:322: recipe for target 'precompiled.hpp.gch' failed >>>>> >>>>> make[4]: Leaving directory '/pathto/linux_ppc64_compiler2/product' >>>>> >>>>> make[4]: *** [precompiled.hpp.gch] Error 1 >>>>> >>>>> /pathto/top.make:119: recipe for target 'the_vm' failed >>>>> >>>>> make[3]: Leaving directory '/pathto/product' >>>>> >>>>> /pathto/make/linux/Makefile:303: recipe for target 'product' failed >>>>> >>>>> make[2]: Leaving directory '/pathto/graal-jvmci-8/build/linux' >>>>> >>>>> Makefile:231: recipe for target 'generic_build2' failed >>>>> >>>>> make[1]: Leaving directory '/pathtoGraal/graal-jvmci-8/make' >>>>> >>>>> make[3]: *** [the_vm] Error 2 >>>>> >>>>> make[2]: *** [product] Error 2 >>>>> >>>>> make[1]: *** [generic_build2] Error 2 >>>>> >>>>> Makefile:182: recipe for target 'product' failed >>>>> >>>>> make: *** [product] Error 2 >>>>> >>>>> make: Leaving directory '/pathto/graal-jvmci-8/make' >>>>> >>>>> Building HotSpot[product, server] failed >>>>> >>>>> 1 build tasks failed >>>>> >>>>> >>>>> >>>>> 3. I dont see jvmci_globals_ppc.hpp in the src tree. But there is another file with name jvmciGlobals_ppc.hpp available in the src tree. I tried to use jvmciGlobals_ppc.hpp, but I get following errors: >>>>> >>>>> /pathto/graal-jvmci-8/src/cpu/ppc/vm/jvmciGlobals_ppc.hpp:35:2: >>>>> error: #error Unimplemented >>>>> >>>>> #error Unimplemented >>>>> >>>>> ^ >>>>> >>>>> /pathto/graal-jvmci-8/make/linux/makefiles/vm.make:322: recipe for >>>>> target 'precompiled.hpp.gch' failed >>>>> >>>>> Please advise if I am missing on something here. >>>>> >>>>> Regards >>>>> Deepali >>>>> >>>>> >>>>> >>>>> DISCLAIMER >>>>> ========== >>>>> This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. >>>>> >>>> >>> >>> DISCLAIMER >>> ========== >>> This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. >>> >> >> >> DISCLAIMER >> ========== >> This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. >> > From russpowers at gmail.com Thu Mar 2 21:51:05 2017 From: russpowers at gmail.com (Russ Powers) Date: Thu, 2 Mar 2017 13:51:05 -0800 Subject: Problem with JVMCI on Cygwin In-Reply-To: References: Message-ID: Thanks Gilles. I've tried running in normal Windows command prompt, but it seems to need sed and find and some other unix utilities, so I tried it using the git/git bash shell, which did work either. After digging around a bit, I noticed it was looking for Cygwin in many places in the build scripts, referring to a HOTSPOTMKSHOME environment variable (which defaults to c:\cygwin\bin). I then tried Cygwin and I got it to fully build and produce the jvm.dll and whole modified jdk folder (although I had to hack mx.py to remove .sha1 checks on downloads, that was causing errors writing .sha1 files). Is there something else I should try? On Thu, Mar 2, 2017 at 5:59 AM, Gilles Duboscq wrote: > Hi Russ, > > When building on Windows, it's probably better not to use Cygwin. > When running on cygwin, mx tries to use some kind of hybrid mode where we > run on cygwin (unix-ish) but target Windows for the JVMCI build. That's > very fragile/hacky. > > Could you try running in a normal windows environment (make sure you use > Windows python, not cygwin python)? > > Unfortunately we have not been testing on windows for a long time so it's > likely that windows support has bit-rotten in both mx and graal-jvmci-8. > > Gilles > > On 02/03/17 14:33, Russ Powers wrote: > > Hello, > > > > I've managed to build JVMCI on Cygwin, and the > > jdk1.8.0_121\product\jre\bin\server > > directory contains the built jvm.dll and jvm.pdb. However, when I try > > using mx on graal-core (with the proper JAVA_HOME set), it gives me this > > error: > > > > The VM does not support the minimum JVMCI API version required by Graal. > > Cannot read JVMCI version from java.vm.version property: > 25.71-b01-internal. > > Set the JVMCI_VERSION_CHECK environment variable to "ignore" to suppress > > this error or to "warn" to emit a warning and continue execution. > > Currently used Java home directory is c:\proj\graal\tools\graal- > > jvmci-8\jdk1.8.0_121\product\jre. > > > > It looks like the JVMCI info is missing, and when I run ./java -version, > it > > doesn't contain the JVMCI info either. I checked, and it's definitely > > using the newly built jvm.dll. Is there something else I should be doing > > here? I'm stumped. Thanks in advance. > > > > Russ > > > From deepali_patel at persistent.com Fri Mar 3 12:37:21 2017 From: deepali_patel at persistent.com (Deepali Patel) Date: Fri, 3 Mar 2017 12:37:21 +0000 Subject: Error while building JVMCI enabled JDK8 on Power In-Reply-To: References: <6B778C59-F1F2-4973-AD86-15C27C9EB335@oracle.com> Message-ID: Hi, Thanks Thalinger and Volker for quick response. Do you think that it is possible to build JVMCI for COMPILER2 only instead of building it for both. Please advise. Regards Deepali -----Original Message----- From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Thursday, March 02, 2017 11:16 PM To: Christian Thalinger Cc: Deepali Patel; graal-dev at openjdk.java.net Subject: Re: Error while building JVMCI enabled JDK8 on Power No, unfortunately not :( We're currently totally overloaded with Java 9 so we won't have time for JVMCI/Graal until after we've released that. Regards, Volker On Thu, Mar 2, 2017 at 6:20 PM, Christian Thalinger wrote: > You should talk to some of the SAP people. Volker, has anyone at SAP thought or even done some work on JVMCI for PPC? > >> On Mar 2, 2017, at 2:17 AM, Deepali Patel wrote: >> >> Hello Doug and Gilles, >> >> I have updated the arch to ppc64le. >> >> Next, I see errors for missing c1_globals_ppc.hpp file. The src/cpu/x86/vm directory contains this file for x86 and also contains many other files for C1. Looks like I will need all these files for PPC as well. However the corresponding directory - src/cpu/ppc/vm does not have these C1 files, although it does have 2 files for C2. Is there any specific reason due to which C1 implementation is not available for ppc or it is just unimplemented currently. Please advise. >> >> Regards >> Deepali >> -----Original Message----- >> From: Deepali Patel >> Sent: Tuesday, February 28, 2017 6:18 PM >> To: 'Doug Simon' >> Cc: Gilles Duboscq; graal-dev at openjdk.java.net >> Subject: RE: Error while building JVMCI enabled JDK8 on Power >> >> Hi Doug, >> >> Thanks for helpful response. >> >> I have copied jvmci/jdk.vm.ci.amd64 and jvmci/jdk.vm.ci.hotspot.amd64 to create jvmci/jdk.vm.ci.ppc64 and jvmci/jdk.vm.ci.hotspot.ppc64 (as suggested by Gilles) respectively. I have modified the source code files to reflect ppc64 instead of amd64 in these folders. >> >> Then I realized that graal-jvmci-8/mx.jvmci/suite.py also needs to be updated to incorporate these new folders. I have also added ppc64le as the supported arch for the Distributions in graal-jvmci-8/mx.jvmci/suite.py. >> >> By default, the ppc64 is set as arch for LE versions as well, however this leads to following error. The jdk source code has jvm.cfg file under ppc64le folder: >> mx --java-home /usr/lib/jvm/java-8-openjdk-ppc64el build >> None >> {'ppc64': {'path': 'build/product/linux/ppc64/server/jvm.tar'}, 'amd64': {'path': 'build/product/linux/amd64/server/jvm.tar'}, 'sparcv9': {'path': 'build/product/linux/sparcv9/server/jvm.tar'}} >> Creating /home/deepali/Graal/graal-jvmci-8/jdk1.8.0_121/product from /usr/lib/jvm/java-8-openjdk-ppc64el >> >> /home/deepali/Graal/graal-jvmci-8/jdk1.8.0_121/product/jre/lib/ppc64/ >> jvm.cfg does not exist >> >> Thus I think I need to update the arch to ppc64le in the makefiles. >> >> Another thing that I noticed is " WARNING: hsdis with flavor 'None' not supported on this plattform or architecture". So looks like I will need to port hsdis as well because it is not available for ppc at https://lafo.ssw.uni-linz.ac.at/pub/hsdis/. >> >> Regards >> Deepali >> >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Friday, February 24, 2017 2:48 PM >> To: Deepali Patel >> Cc: Gilles Duboscq; graal-dev at openjdk.java.net >> Subject: Re: Error while building JVMCI enabled JDK8 on Power >> >> >>> On 24 Feb 2017, at 09:20, Deepali Patel wrote: >>> >>> Thanks Doug and Gilles for quick response. >>> >>> Could you please throw some more light on the parts of code(folders, files etc) that will need to be updated/modified to get this working on PPC. Would we need assembly code as well? If so, could you please point me to the corresponding x86 files for reference. >> >> dsimon at kurz-3 ~/g/graal-jvmci-8> find src | grep jvmci | grep x86 >> src/cpu/x86/vm/jvmci_globals_x86.hpp >> src/cpu/x86/vm/jvmciCodeInstaller_x86.cpp >> dsimon at kurz-3 ~/g/graal-jvmci-8> find src | grep jvmci | grep sparc >> src/cpu/sparc/vm/jvmci_globals_sparc.hpp >> src/cpu/sparc/vm/jvmciCodeInstaller_sparc.cpp >> >> dsimon at kurz-3 ~/g/graal-core> ls -d graal/*sparc* >> graal/org.graalvm.compiler.asm.sparc graal/org.graalvm.compiler.core.sparc.test graal/org.graalvm.compiler.replacements.sparc >> graal/org.graalvm.compiler.asm.sparc.test graal/org.graalvm.compiler.hotspot.sparc graal/org.graalvm.compiler.truffle.hotspot.sparc >> graal/org.graalvm.compiler.core.sparc graal/org.graalvm.compiler.lir.sparc >> dsimon at kurz-3 ~/g/graal-core> ls -d graal/*amd64* >> graal/org.graalvm.compiler.asm.amd64 graal/org.graalvm.compiler.core.amd64.test graal/org.graalvm.compiler.lir.amd64 >> graal/org.graalvm.compiler.asm.amd64.test graal/org.graalvm.compiler.hotspot.amd64 graal/org.graalvm.compiler.replacements.amd64 >> graal/org.graalvm.compiler.core.amd64 graal/org.graalvm.compiler.hotspot.amd64.test graal/org.graalvm.compiler.truffle.hotspot.amd64 >> >> Hope that helps, >> >> -Doug >> >>> -----Original Message----- >>> From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On >>> Behalf Of Gilles Duboscq >>> Sent: Thursday, February 23, 2017 5:02 PM >>> To: graal-dev at openjdk.java.net >>> Subject: Re: Error while building JVMCI enabled JDK8 on Power >>> >>> You will also need to implement the Java side of things. >>> See for example the sources in jvmci/jdk.vm.ci.amd64 and jvmci/jdk.vm.ci.hotspot.amd64. >>> >>> Gilles >>> >>> On 23/02/17 11:26, Doug Simon wrote: >>>> Hi Deepali, >>>> >>>> This is an interesting but non-trivial project I suspect. You will need to look at all the machine specific JVMCI files and create corresponding *_ppc.[hpp|cpp] files. The existing jvmciGlobals_ppc.hpp needs to be renamed to jvmci_globals_ppc.hpp (as you observed) and completed as part of this. >>>> >>>> -Doug >>>> >>>>> On 23 Feb 2017, at 10:41, Deepali Patel wrote: >>>>> >>>>> Hello Team, >>>>> >>>>> I am trying to build Graal core on Power. >>>>> >>>>> >>>>> 1. I have updated mx.py to allow build on Power: >>>>> ----------------- >>>>> diff --git a/mx.py b/mx.py >>>>> index 172609d..de932f6 100755 >>>>> --- a/mx.py >>>>> +++ b/mx.py >>>>> @@ -7369,6 +7369,8 @@ def get_arch(): >>>>> except OSError: >>>>> # sysctl is not available >>>>> pass >>>>> + if machine == 'ppc64le' and get_os() == 'linux': >>>>> + return 'ppc64le' >>>>> abort('unknown or unsupported architecture: os=' + get_os() + ', >>>>> machine=' + machine) >>>>> >>>>> mx_subst.results_substitutions.register_no_arg('arch', get_arch) >>>>> ------------------------------ >>>>> >>>>> >>>>> 2. Next I am trying to build building JVMCI enabled JDK8. However, I see following error: >>>>> >>>>> Generating precompiled header precompiled.hpp.gch >>>>> >>>>> In file included from /pathto/allocation.hpp:28:0, >>>>> >>>>> from /pathto/iterator.hpp:28, >>>>> >>>>> from /pathto/genOopClosures.hpp:28, >>>>> >>>>> from /pathto/klass.hpp:28, >>>>> >>>>> from /pathto/handles.hpp:28, >>>>> >>>>> from /pathto/universe.hpp:28, >>>>> >>>>> from /pathto/oopRecorder.hpp:28, >>>>> >>>>> from /pathto/codeBuffer.hpp:28, >>>>> >>>>> from /pathto/assembler.hpp:28, >>>>> >>>>> from /pathto/precompiled.hpp:29: >>>>> >>>>> /pathto/globals.hpp:143:34: fatal error: jvmci_globals_ppc.hpp: No >>>>> such file or directory >>>>> >>>>> compilation terminated. >>>>> >>>>> /pathto/vm.make:322: recipe for target 'precompiled.hpp.gch' >>>>> failed >>>>> >>>>> make[4]: Leaving directory '/pathto/linux_ppc64_compiler2/product' >>>>> >>>>> make[4]: *** [precompiled.hpp.gch] Error 1 >>>>> >>>>> /pathto/top.make:119: recipe for target 'the_vm' failed >>>>> >>>>> make[3]: Leaving directory '/pathto/product' >>>>> >>>>> /pathto/make/linux/Makefile:303: recipe for target 'product' >>>>> failed >>>>> >>>>> make[2]: Leaving directory '/pathto/graal-jvmci-8/build/linux' >>>>> >>>>> Makefile:231: recipe for target 'generic_build2' failed >>>>> >>>>> make[1]: Leaving directory '/pathtoGraal/graal-jvmci-8/make' >>>>> >>>>> make[3]: *** [the_vm] Error 2 >>>>> >>>>> make[2]: *** [product] Error 2 >>>>> >>>>> make[1]: *** [generic_build2] Error 2 >>>>> >>>>> Makefile:182: recipe for target 'product' failed >>>>> >>>>> make: *** [product] Error 2 >>>>> >>>>> make: Leaving directory '/pathto/graal-jvmci-8/make' >>>>> >>>>> Building HotSpot[product, server] failed >>>>> >>>>> 1 build tasks failed >>>>> >>>>> >>>>> >>>>> 3. I dont see jvmci_globals_ppc.hpp in the src tree. But there is another file with name jvmciGlobals_ppc.hpp available in the src tree. I tried to use jvmciGlobals_ppc.hpp, but I get following errors: >>>>> >>>>> /pathto/graal-jvmci-8/src/cpu/ppc/vm/jvmciGlobals_ppc.hpp:35:2: >>>>> error: #error Unimplemented >>>>> >>>>> #error Unimplemented >>>>> >>>>> ^ >>>>> >>>>> /pathto/graal-jvmci-8/make/linux/makefiles/vm.make:322: recipe for >>>>> target 'precompiled.hpp.gch' failed >>>>> >>>>> Please advise if I am missing on something here. >>>>> >>>>> Regards >>>>> Deepali >>>>> >>>>> >>>>> >>>>> DISCLAIMER >>>>> ========== >>>>> This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. >>>>> >>>> >>> >>> DISCLAIMER >>> ========== >>> This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. >>> >> >> >> DISCLAIMER >> ========== >> This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. >> > DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. From cthalinger at twitter.com Fri Mar 3 20:27:13 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Fri, 3 Mar 2017 10:27:13 -1000 Subject: Error while building JVMCI enabled JDK8 on Power In-Reply-To: References: <6B778C59-F1F2-4973-AD86-15C27C9EB335@oracle.com> Message-ID: > On Mar 3, 2017, at 2:37 AM, Deepali Patel wrote: > > Hi, > > Thanks Thalinger and Volker for quick response. > > Do you think that it is possible to build JVMCI for COMPILER2 only instead of building it for both. Please advise. You mean build a VM with C2 only? Sure you can. > > Regards > Deepali > > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Thursday, March 02, 2017 11:16 PM > To: Christian Thalinger > Cc: Deepali Patel; graal-dev at openjdk.java.net > Subject: Re: Error while building JVMCI enabled JDK8 on Power > > No, unfortunately not :( > We're currently totally overloaded with Java 9 so we won't have time for JVMCI/Graal until after we've released that. > > Regards, > Volker > > > On Thu, Mar 2, 2017 at 6:20 PM, Christian Thalinger wrote: >> You should talk to some of the SAP people. Volker, has anyone at SAP thought or even done some work on JVMCI for PPC? >> >>> On Mar 2, 2017, at 2:17 AM, Deepali Patel wrote: >>> >>> Hello Doug and Gilles, >>> >>> I have updated the arch to ppc64le. >>> >>> Next, I see errors for missing c1_globals_ppc.hpp file. The src/cpu/x86/vm directory contains this file for x86 and also contains many other files for C1. Looks like I will need all these files for PPC as well. However the corresponding directory - src/cpu/ppc/vm does not have these C1 files, although it does have 2 files for C2. Is there any specific reason due to which C1 implementation is not available for ppc or it is just unimplemented currently. Please advise. >>> >>> Regards >>> Deepali >>> -----Original Message----- >>> From: Deepali Patel >>> Sent: Tuesday, February 28, 2017 6:18 PM >>> To: 'Doug Simon' >>> Cc: Gilles Duboscq; graal-dev at openjdk.java.net >>> Subject: RE: Error while building JVMCI enabled JDK8 on Power >>> >>> Hi Doug, >>> >>> Thanks for helpful response. >>> >>> I have copied jvmci/jdk.vm.ci.amd64 and jvmci/jdk.vm.ci.hotspot.amd64 to create jvmci/jdk.vm.ci.ppc64 and jvmci/jdk.vm.ci.hotspot.ppc64 (as suggested by Gilles) respectively. I have modified the source code files to reflect ppc64 instead of amd64 in these folders. >>> >>> Then I realized that graal-jvmci-8/mx.jvmci/suite.py also needs to be updated to incorporate these new folders. I have also added ppc64le as the supported arch for the Distributions in graal-jvmci-8/mx.jvmci/suite.py. >>> >>> By default, the ppc64 is set as arch for LE versions as well, however this leads to following error. The jdk source code has jvm.cfg file under ppc64le folder: >>> mx --java-home /usr/lib/jvm/java-8-openjdk-ppc64el build >>> None >>> {'ppc64': {'path': 'build/product/linux/ppc64/server/jvm.tar'}, 'amd64': {'path': 'build/product/linux/amd64/server/jvm.tar'}, 'sparcv9': {'path': 'build/product/linux/sparcv9/server/jvm.tar'}} >>> Creating /home/deepali/Graal/graal-jvmci-8/jdk1.8.0_121/product from /usr/lib/jvm/java-8-openjdk-ppc64el >>> >>> /home/deepali/Graal/graal-jvmci-8/jdk1.8.0_121/product/jre/lib/ppc64/ >>> jvm.cfg does not exist >>> >>> Thus I think I need to update the arch to ppc64le in the makefiles. >>> >>> Another thing that I noticed is " WARNING: hsdis with flavor 'None' not supported on this plattform or architecture". So looks like I will need to port hsdis as well because it is not available for ppc at https://lafo.ssw.uni-linz.ac.at/pub/hsdis/. >>> >>> Regards >>> Deepali >>> >>> -----Original Message----- >>> From: Doug Simon [mailto:doug.simon at oracle.com] >>> Sent: Friday, February 24, 2017 2:48 PM >>> To: Deepali Patel >>> Cc: Gilles Duboscq; graal-dev at openjdk.java.net >>> Subject: Re: Error while building JVMCI enabled JDK8 on Power >>> >>> >>>> On 24 Feb 2017, at 09:20, Deepali Patel wrote: >>>> >>>> Thanks Doug and Gilles for quick response. >>>> >>>> Could you please throw some more light on the parts of code(folders, files etc) that will need to be updated/modified to get this working on PPC. Would we need assembly code as well? If so, could you please point me to the corresponding x86 files for reference. >>> >>> dsimon at kurz-3 ~/g/graal-jvmci-8> find src | grep jvmci | grep x86 >>> src/cpu/x86/vm/jvmci_globals_x86.hpp >>> src/cpu/x86/vm/jvmciCodeInstaller_x86.cpp >>> dsimon at kurz-3 ~/g/graal-jvmci-8> find src | grep jvmci | grep sparc >>> src/cpu/sparc/vm/jvmci_globals_sparc.hpp >>> src/cpu/sparc/vm/jvmciCodeInstaller_sparc.cpp >>> >>> dsimon at kurz-3 ~/g/graal-core> ls -d graal/*sparc* >>> graal/org.graalvm.compiler.asm.sparc graal/org.graalvm.compiler.core.sparc.test graal/org.graalvm.compiler.replacements.sparc >>> graal/org.graalvm.compiler.asm.sparc.test graal/org.graalvm.compiler.hotspot.sparc graal/org.graalvm.compiler.truffle.hotspot.sparc >>> graal/org.graalvm.compiler.core.sparc graal/org.graalvm.compiler.lir.sparc >>> dsimon at kurz-3 ~/g/graal-core> ls -d graal/*amd64* >>> graal/org.graalvm.compiler.asm.amd64 graal/org.graalvm.compiler.core.amd64.test graal/org.graalvm.compiler.lir.amd64 >>> graal/org.graalvm.compiler.asm.amd64.test graal/org.graalvm.compiler.hotspot.amd64 graal/org.graalvm.compiler.replacements.amd64 >>> graal/org.graalvm.compiler.core.amd64 graal/org.graalvm.compiler.hotspot.amd64.test graal/org.graalvm.compiler.truffle.hotspot.amd64 >>> >>> Hope that helps, >>> >>> -Doug >>> >>>> -----Original Message----- >>>> From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On >>>> Behalf Of Gilles Duboscq >>>> Sent: Thursday, February 23, 2017 5:02 PM >>>> To: graal-dev at openjdk.java.net >>>> Subject: Re: Error while building JVMCI enabled JDK8 on Power >>>> >>>> You will also need to implement the Java side of things. >>>> See for example the sources in jvmci/jdk.vm.ci.amd64 and jvmci/jdk.vm.ci.hotspot.amd64. >>>> >>>> Gilles >>>> >>>> On 23/02/17 11:26, Doug Simon wrote: >>>>> Hi Deepali, >>>>> >>>>> This is an interesting but non-trivial project I suspect. You will need to look at all the machine specific JVMCI files and create corresponding *_ppc.[hpp|cpp] files. The existing jvmciGlobals_ppc.hpp needs to be renamed to jvmci_globals_ppc.hpp (as you observed) and completed as part of this. >>>>> >>>>> -Doug >>>>> >>>>>> On 23 Feb 2017, at 10:41, Deepali Patel wrote: >>>>>> >>>>>> Hello Team, >>>>>> >>>>>> I am trying to build Graal core on Power. >>>>>> >>>>>> >>>>>> 1. I have updated mx.py to allow build on Power: >>>>>> ----------------- >>>>>> diff --git a/mx.py b/mx.py >>>>>> index 172609d..de932f6 100755 >>>>>> --- a/mx.py >>>>>> +++ b/mx.py >>>>>> @@ -7369,6 +7369,8 @@ def get_arch(): >>>>>> except OSError: >>>>>> # sysctl is not available >>>>>> pass >>>>>> + if machine == 'ppc64le' and get_os() == 'linux': >>>>>> + return 'ppc64le' >>>>>> abort('unknown or unsupported architecture: os=' + get_os() + ', >>>>>> machine=' + machine) >>>>>> >>>>>> mx_subst.results_substitutions.register_no_arg('arch', get_arch) >>>>>> ------------------------------ >>>>>> >>>>>> >>>>>> 2. Next I am trying to build building JVMCI enabled JDK8. However, I see following error: >>>>>> >>>>>> Generating precompiled header precompiled.hpp.gch >>>>>> >>>>>> In file included from /pathto/allocation.hpp:28:0, >>>>>> >>>>>> from /pathto/iterator.hpp:28, >>>>>> >>>>>> from /pathto/genOopClosures.hpp:28, >>>>>> >>>>>> from /pathto/klass.hpp:28, >>>>>> >>>>>> from /pathto/handles.hpp:28, >>>>>> >>>>>> from /pathto/universe.hpp:28, >>>>>> >>>>>> from /pathto/oopRecorder.hpp:28, >>>>>> >>>>>> from /pathto/codeBuffer.hpp:28, >>>>>> >>>>>> from /pathto/assembler.hpp:28, >>>>>> >>>>>> from /pathto/precompiled.hpp:29: >>>>>> >>>>>> /pathto/globals.hpp:143:34: fatal error: jvmci_globals_ppc.hpp: No >>>>>> such file or directory >>>>>> >>>>>> compilation terminated. >>>>>> >>>>>> /pathto/vm.make:322: recipe for target 'precompiled.hpp.gch' >>>>>> failed >>>>>> >>>>>> make[4]: Leaving directory '/pathto/linux_ppc64_compiler2/product' >>>>>> >>>>>> make[4]: *** [precompiled.hpp.gch] Error 1 >>>>>> >>>>>> /pathto/top.make:119: recipe for target 'the_vm' failed >>>>>> >>>>>> make[3]: Leaving directory '/pathto/product' >>>>>> >>>>>> /pathto/make/linux/Makefile:303: recipe for target 'product' >>>>>> failed >>>>>> >>>>>> make[2]: Leaving directory '/pathto/graal-jvmci-8/build/linux' >>>>>> >>>>>> Makefile:231: recipe for target 'generic_build2' failed >>>>>> >>>>>> make[1]: Leaving directory '/pathtoGraal/graal-jvmci-8/make' >>>>>> >>>>>> make[3]: *** [the_vm] Error 2 >>>>>> >>>>>> make[2]: *** [product] Error 2 >>>>>> >>>>>> make[1]: *** [generic_build2] Error 2 >>>>>> >>>>>> Makefile:182: recipe for target 'product' failed >>>>>> >>>>>> make: *** [product] Error 2 >>>>>> >>>>>> make: Leaving directory '/pathto/graal-jvmci-8/make' >>>>>> >>>>>> Building HotSpot[product, server] failed >>>>>> >>>>>> 1 build tasks failed >>>>>> >>>>>> >>>>>> >>>>>> 3. I dont see jvmci_globals_ppc.hpp in the src tree. But there is another file with name jvmciGlobals_ppc.hpp available in the src tree. I tried to use jvmciGlobals_ppc.hpp, but I get following errors: >>>>>> >>>>>> /pathto/graal-jvmci-8/src/cpu/ppc/vm/jvmciGlobals_ppc.hpp:35:2: >>>>>> error: #error Unimplemented >>>>>> >>>>>> #error Unimplemented >>>>>> >>>>>> ^ >>>>>> >>>>>> /pathto/graal-jvmci-8/make/linux/makefiles/vm.make:322: recipe for >>>>>> target 'precompiled.hpp.gch' failed >>>>>> >>>>>> Please advise if I am missing on something here. >>>>>> >>>>>> Regards >>>>>> Deepali >>>>>> >>>>>> >>>>>> >>>>>> DISCLAIMER >>>>>> ========== >>>>>> This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. >>>>>> >>>>> >>>> >>>> DISCLAIMER >>>> ========== >>>> This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. >>>> >>> >>> >>> DISCLAIMER >>> ========== >>> This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. >>> >> > > DISCLAIMER > ========== > This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. > From tom.rodriguez at oracle.com Mon Mar 6 23:31:41 2017 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 06 Mar 2017 15:31:41 -0800 Subject: RFR: AArch64: Implementing address lowering to make use of immediate address mode In-Reply-To: <68ee82f2-c230-76de-b6bc-88ada8a73e85@redhat.com> References: <206f2ccf-7e37-1b7b-3f30-7b319ddb6534@redhat.com> <58B61837.60107@oracle.com> <68ee82f2-c230-76de-b6bc-88ada8a73e85@redhat.com> Message-ID: <58BDF15D.5060901@oracle.com> Andrew Dinn wrote: > Hi Tom, > > > On 01/03/17 00:39, Tom Rodriguez wrote: >> There's nothing about the AddressLoweringPhase that says the mapping of >> old the OffsetAddressNode to machine dependent address mode must be one >> to one. You are free to examine the usages and generate a distinct >> address node for each use. GVN will common any duplicates back >> together. You still will need to select the right forms for the backend >> so it doesn't address all the problems you mention. > > Thanks very much for replying. I'm not quite sure I follow what you are > saying but let me try to confirm that I am on the right track. > > I do understand that each usage of some given OffsetAddress can be > substituted /per usage/ by an appropriate AArch64AddressNode without > fear of introducing unnecessary replicas. The thrust of your comment > seems to be that my current patch doesn't actually need to detect a > single, unique LIRKind for all usages in order to be able to embed a > constant index as displacement. It could instead traverse all usages > and, where possible, replace the OffsetAddress referenced from the usage > with a lowered AddressNode employing a displacement constructed > according to the LIRKind of that usage. > > Is that what you are suggesting? Yes. > If so then I agree that I might perhaps > be able tweak the patch to do this. However, that's really somewhat > incidental to the concerns I originally raised, perhaps even providing > an a fortiori argument for addressing them. The AddressLowering phase is > given an AddressNode to lower, a node which may be shared by multiple > usages. It is not given a usage (i.e. a node using the AddressNode) and > asked whether it wants to provide a lowered address node specific to > that usage. > > So, the problem remains that the lowering model AddressLowering has > adopted is based on a misguided notion that lowering can be scheduled > per AddressNode without reference to usage. I really want to try to fix > the model not the current patch. Well the model was adequate for the platforms we supported at the time which is why I think it was chosen. The current AddressLoweringPhase/AddressLowering logic is simple enough that I'm not sure it really makes sense to make it complex just to support AArch64. I'd probably just write a custom phase to do what needs to be done, and factor out the creation of the address lowering phase in HotSpotSuitesProvider so that an AArch64HotSpotSuitesProvider could provide it's own completely custom implementation. I'd probably directly pass in the required AArch64HotSpotLIRKindTool as well which you can just construct by hand. It could that the the kind tool should be part of the HotSpotProviders instead of buried in the LIRGenerator but it hasn't needed to be more visible until now. It seems like you would have everything required for proper code generation then. > > If your point is that AddressLowering ought, perhaps, to be rewritten to > operate by considering each usage in turn then that would indeed be a > better model. > > Apologies if I am barking up the wrong tree entirely here and have not > grasped what you are getting at. > > Of course, m comments about the need to have access to the usage kind > (and, hence, to a KindTool) and my failure to understand how a derived > LIRKind should be computed for any lowered AddressNode also still stand > in the hope of some comment or explanation which would, of course, be > gratefully received. As far as the LIRKind of an AddressValue most of the time it is actually completely unused. The purpose of the derived information is for tracking when a pointer into the middle of a Java object has been materialized as a value so that it can be described to the garbage collector or for error checking that a derived value isn't live across a safepoint. The LIRKind of an AddressValue is the LIRKind of the address as a computation but the LIRKind of the memory operation is LIRKind of the datum being transferred so they are only loosely related. So the only case where the LIRKind of an address value will ever appear as a value is for an LEA style operation. I suspect I haven't addressed all your concerns about the LIRKind for addresses so please follow up with any clarifying questions. tom > > regards, > > > Andrew Dinn > ----------- > >> Andrew Dinn wrote: >>> I have patched (a slightly out of date version of) Graal to allow >>> AArch64 to make use of scaled and unscaled immediate addressing. This >>> generates much better code but the implementation is 'wrong' in several >>> important respects. A pull request including the change is available here >>> >>> https://github.com/graalvm/graal-core/pull/258 >>> >>> I have no wish for this change to be included as is - I posted it merely >>> to enable discussion of what is really needed. >>> >>> The patch deliberately bypasses the normal AddressLowering phase (I'll >>> explain why in a second). Instead it intercepts translation of addresses >>> during the generate phase. Basically, it attempts to improve addresses >>> initially generated as an OffsetAddress (i.e. supplied with 2 Values, >>> base and index) when the index is an integer constant whcih can be >>> embedded as an immediate displacement (I guess it ought to handle the >>> reverse case where base is a constant and index a general Value but >>> nothing appears to be generating addresses with constants in that >>> order). It does so by 'nulling' the index saving the constant as a >>> displacement and resetting the addressing mode from register offset to >>> scaled or unscaled immediate. >>> >>> So, before applying the patch addresses with constant index were >>> 'improved' by replacing the constant node with a constant load and >>> relying on the use of register_offset addressing mode to do the actual >>> memory operation. The result is code like this: >>> >>> movz x3, #0xc # constant load of offset value >>> movk x3, #0x0, lsl #16 >>> ldr w1 [x2, x3] # (1) load via register_offset addressing >>> >>> The patch tries instead to transform the node to use either scaled or >>> unscaled immediate addressing resulting, respectively, in code like this: >>> >>> ldr w1, [x2,#12] # (2) load via scaled immediate addressing >>> >>> or (let's assume we had a negative offset mandating an unscaled load) >>> >>> ldr w1, [x2, #-12] # (3) load via unscaled immediate addressing >>> >>> There are two related reasons why this has been done in the Generate >>> phase rather than in the AddressLowering phase. I present them both in >>> turn below in order to pose some questions about why AddressLowering is >>> currently done as is and to suggest what might be needed to fix it. >>> >>> I have also include a critique of the way a derived LIRKind is computed >>> for the AddressValue returned by method generate(). I am unclear why it >>> is currently being computed as is and also unclear what would be an >>> appropriate derived value when immediates are encoded. Advice or >>> comments regarding the patch and the following critique would be very >>> welcome. >>> >>> Scaling depends on the transfer size >>> ------------------------------------ >>> >>> The first problem is that for scaled memory addressing the decision as >>> to whether or not a given constant index can be embedded as an immediate >>> constant in the address node depends upon how the address is used by one >>> or more memory ops. >>> >>> In code example (2) which uses scaled addressing above the load >>> instruction is transferring a 32 bit datum (as indicated in the assembly >>> code by the target register being named w1). The load address is the 64 >>> bit value in r1 (as indicated in the assembly code by the base register >>> being named x1) plus constant offset 12. >>> >>> A scaled immediate memory op can embed a 12 bit unsigned displacement. >>> However, the unit size for the embedded value is determined by the size >>> of the accessed datum. So, for a 32 bit load/store the set of offsets >>> which are valid is {4, 8, ... 4 * (2^12 - 1)}. For a byte load the set >>> of valid offsets is {1, 2, ... (2^12-1)}. >>> >>> Obviously, as the name clearly indicates, there is no dependency on >>> transfer size when using unscaled addressing. Memory ops employing this >>> latter addressing may embed any signed 9-bit displacement which is >>> always counted in a unit size of bytes. So, translation to use unscaled >>> addressing in the AddressLowering phase doesn't present any great >>> problem. However, generating the best code requires implementing both >>> modes. >>> >>> The upshot is that in order to determine whether a constant index can be >>> replaced by an immediate node the lowering code needs to investigate >>> usages of the address node and establish that all usages employ a unique >>> transfer size. >>> >>> As you can see in the pull request, the patch includes a method >>> getUsageSize() which does that job. It traverses all usages and returns >>> either a single platform kind which defines a transfer size common to >>> all usages or null if no such unique common kind exists. This leads to >>> the second problem. (n.b. I have finessed Prefetch usages for now >>> because the current AArch64 Graal does not generate code for prefetch. >>> That will need fixing when it is implemented). >>> >>> Identification of the platform kind requires a generator >>> -------------------------------------------------------- >>> >>> The above requirement explains why the lowering code is implemented as >>> part of the Generate phase instead of in the AddressLowering phase. >>> Identifying the PlatformKind associated with a specific usage of the >>> AddressNode requires translating the stamp of each usage to an LIRKind. >>> That mandates availability of a suitable instance of LIRKindTool >>> (actually an AArch64LIRKindTool) which parameterizes the call to >>> getUsageSize(). The KindTool must be obtained from the >>> AArch64LIRGenerator tool which is obtained form the NodeLIRBuilderTool >>> passed to the AArch64AddressNode generate() method. >>> >>> I don't doubt that here is some sneaky way of ensuring that the >>> AArch64AddressLowering instance obtains access to an AArch64LIRGenerator >>> (and, thence, an AArch64LIRKindTool) behind the scenes. However, >>> implementing a solution like that does not really seem to me to be the >>> correct solution. There is an assumption in the current code that >>> address lowering can be done prior to the Generate phase without needing >>> to identify whatever transfer datum and/or transfer size is at stake >>> when the address is being used. That's a broken assumption and I would >>> prefer to fix it. >>> >>> One solution would be to have the generic code precompute the common >>> usage LIRKind and pass it to the implementation class which extends >>> AddressLowering. Alternatively, the abstract parent class could provide >>> a convenience method allowing a suitable PlatformKind to be computed. >>> Either way this means that the parent needs to know about the Arch and >>> know how to obtain an arch-specific KindTool. I'm happy to look into >>> proposing a solution along these lines but I'd like to canvas here for >>> comments before doing so. >>> >>> Another alternative would be to perform address lowering at a later >>> stage, perhaps in the back end even. This would perhaps require doing >>> some of the transforms done in e.g. AMD64AddressLowering as generic >>> transforms and having a generic AddressNode which allowed for a >>> non-constant index and/or constant displacement. I'm also happy to >>> consider how this might work but I'd probably need more advice about how >>> to go about this. >>> >>> >>> The LIRKind of the resulting AddressValue -- is it correct? >>> ----------------------------------------------------------- >>> >>> The patch in the pull request attempts to follow the logic of the >>> preceding code in deriving an LIRKind for whatever AddressNode it >>> constructs, whether using register offset or immediate addressing. >>> However, I am not sure what the original logic is. >>> >>> In the original code for AArch64AddressNode.generate() the case where >>> the either base or index was null is treated by setting, respectively, >>> baseValue or indexValue to Value.ILLEGAL. Later in that original code >>> this implies that indexReference is also set to Value.ILLEGAL. The >>> LIRKind for the final resulting AArch64AddressValue is computed by >>> executing >>> >>> LIRKind kind = LIRKind.combineDerived(tool.getLIRKind(stamp()), >>> baseReference, indexReference); >>> >>> So, when base is, say, a register and index is null this represents a >>> direct reference through a register with no offset. I would have >>> expected that in this circumstance there was some coherent way of >>> deriving the LIRKind of the address from the LIRKind associated with >>> base. However, because index is null, so indexValue is Value.ILLEGAL and >>> hence indexReference is also Value.ILLEGAL. combineDerived handles this >>> case by returning an unknown reference derived from the stamp(). By >>> contrast, if indexReference was null then combineDerived would compute >>> the combined reference by calling makeDerivedReference(base). >>> >>> My patch follows this code by starting off with indexValue = null then >>> resetting it to Value.ILLEGAL either if it is null or if it is possible >>> to intervene and replace a constant index with a displacement. >>> Otherwise, when we have a non-null index, indexValue is computed as >>> before by executing >>> >>> indexValue = tool.asAllocatable(gen.operand(index)); >>> >>> I have also preserved the original special case processing for >>> AddressingMode.IMMEDIATE_UNSCALED where the indexReference is derived by >>> executing >>> >>> indexReference = LIRKind.derivedBaseFromValue(indexValue); >>> >>> although I'll note that in cases where that addressing mode is >>> introduced by replacing a constant index with an unscaled displacement >>> indexValue will be Value.ILLEGAL and hence the indexReference will be >>> returned as Value.ILLEGAL which seems to negate the purpose of that >>> special case handling. >>> >>> I am suspicious that all of this computation seems to be rather >>> redundant anyway. At the point of use of an Address to encode a Load or >>> Store (or possibly a Prefetch) the LIRKind of the address appears to be >>> ignored and instead the LIRKind of the transfer datum is used to >>> generate the load. Is this computation of the derived actually achieving >>> anything important? >>> >>> regards, >>> >>> >>> Andrew Dinn >>> ----------- >>> Senior Principal Software Engineer >>> Red Hat UK Ltd >>> Registered in England and Wales under Company Registration No. 03798903 >>> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From deepali_patel at persistent.com Tue Mar 7 09:06:42 2017 From: deepali_patel at persistent.com (Deepali Patel) Date: Tue, 7 Mar 2017 09:06:42 +0000 Subject: Error - Cannot read JVMCI version from java.vm.version property Message-ID: Hello, I am using a Ubuntu 16.04.2 x86_64 system. The java version is: openjdk version "1.8.0_121" OpenJDK Runtime Environment (build 1.8.0_121-8u121-b13-0ubuntu1.16.04.2-b13) OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode) I used the steps in the section https://github.com/graalvm/graal-core#building-jvmci-jdk8 to build JVMCI JDK8. The build is successful, the last few lines of output is like: make: Leaving directory '/pathto/Graal/graal-jvmci-8/make' Compiling jdk.vm.ci.hotspot.amd64 with javac-daemon... [dependency jdk.vm.ci.amd64 updated] Compiling jdk.vm.ci.hotspot.sparc with javac-daemon... [dependency jdk.vm.ci.sparc updated] Compiling jdk.vm.ci.hotspot.aarch64 with javac-daemon... [dependency jdk.vm.ci.aarch64 updated] Archiving JVMCI_TEST... [dependency jdk.vm.ci.runtime.test updated] Archiving JVM_PRODUCT_SERVER... [dependency hotspot updated] Archiving JVMCI_HOTSPOT... [dependency jdk.vm.ci.hotspot.aarch64 updated] And I update JAVA_HOME using export JAVA_HOME=$(mx --java-home /usr/lib/jvm/java-8-openjdk-amd64 jdkhome) echo $JAVA_HOME shows: /pathto/Graal/graal-jvmci-8/jdk1.8.0_121/product Next I checkout graal-core and execute mx on it. The error seen is: The VM does not support the minimum JVMCI API version required by Graal. Cannot read JVMCI version from java.vm.version property: 25.121-b13. Set the JVMCI_VERSION_CHECK environment variable to "ignore" to suppress this error or to "warn" to emit a warning and continue execution. Currently used Java home directory is /usr/lib/jvm/java-8-openjdk-amd64/jre. Currently used VM configuration is: OpenJDK 64-Bit Server VM Download the latest JVMCI JDK 8 from http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html Please suggest if I have missed out anything here. I do not want to download the built version of JVMCI because in parallel I am working on building it on PPC. Regards Deepali DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. From doug.simon at oracle.com Tue Mar 7 09:48:13 2017 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 7 Mar 2017 10:48:13 +0100 Subject: Error - Cannot read JVMCI version from java.vm.version property In-Reply-To: References: Message-ID: <04958CF4-3AB8-47F3-936F-0C12D25F00B1@oracle.com> > On 7 Mar 2017, at 10:06, Deepali Patel wrote: > > Hello, > > I am using a Ubuntu 16.04.2 x86_64 system. > > The java version is: > openjdk version "1.8.0_121" > OpenJDK Runtime Environment (build 1.8.0_121-8u121-b13-0ubuntu1.16.04.2-b13) > OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode) > > I used the steps in the section https://github.com/graalvm/graal-core#building-jvmci-jdk8 to build JVMCI JDK8. The build is successful, the last few lines of output is like: > make: Leaving directory '/pathto/Graal/graal-jvmci-8/make' > Compiling jdk.vm.ci.hotspot.amd64 with javac-daemon... [dependency jdk.vm.ci.amd64 updated] > Compiling jdk.vm.ci.hotspot.sparc with javac-daemon... [dependency jdk.vm.ci.sparc updated] > Compiling jdk.vm.ci.hotspot.aarch64 with javac-daemon... [dependency jdk.vm.ci.aarch64 updated] > Archiving JVMCI_TEST... [dependency jdk.vm.ci.runtime.test updated] > Archiving JVM_PRODUCT_SERVER... [dependency hotspot updated] > Archiving JVMCI_HOTSPOT... [dependency jdk.vm.ci.hotspot.aarch64 updated] > > And I update JAVA_HOME using > export JAVA_HOME=$(mx --java-home /usr/lib/jvm/java-8-openjdk-amd64 jdkhome) > > echo $JAVA_HOME shows: > /pathto/Graal/graal-jvmci-8/jdk1.8.0_121/product > > Next I checkout graal-core and execute mx on it. > > The error seen is: > The VM does not support the minimum JVMCI API version required by Graal. > Cannot read JVMCI version from java.vm.version property: 25.121-b13. > Set the JVMCI_VERSION_CHECK environment variable to "ignore" to suppress this error or to "warn" to emit a warning and continue execution. > Currently used Java home directory is /usr/lib/jvm/java-8-openjdk-amd64/jre. > Currently used VM configuration is: OpenJDK 64-Bit Server VM > Download the latest JVMCI JDK 8 from http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html > > Please suggest if I have missed out anything here. I do not want to download the built version of JVMCI because in parallel I am working on building it on PPC. It seems like your $JAVA_HOME env var has a problem otherwise mx should be picking up /pathto/Graal/graal-jvmci-8/jdk1.8.0_121/product not /usr/lib/jvm/java-8-openjdk-amd64/jre. Do you really have a root directory on your system named "pathto"? You can use the --java-home option to mx instead of JAVA_HOME: mx --java-home /pathto/Graal/graal-jvmci-8/jdk1.8.0_121/product ... -Doug From deepali_patel at persistent.com Tue Mar 7 10:07:50 2017 From: deepali_patel at persistent.com (Deepali Patel) Date: Tue, 7 Mar 2017 10:07:50 +0000 Subject: Error - Cannot read JVMCI version from java.vm.version property In-Reply-To: <04958CF4-3AB8-47F3-936F-0C12D25F00B1@oracle.com> References: <04958CF4-3AB8-47F3-936F-0C12D25F00B1@oracle.com> Message-ID: Yes looks like some issue with the env variable. I do not have a directory called "pathto". I just pasted that instead of putting the path of directory where Graal is present. I tried everything all over and it worked. Regards Deepali -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Tuesday, March 07, 2017 3:18 PM To: Deepali Patel Cc: graal-dev at openjdk.java.net Subject: Re: Error - Cannot read JVMCI version from java.vm.version property > On 7 Mar 2017, at 10:06, Deepali Patel wrote: > > Hello, > > I am using a Ubuntu 16.04.2 x86_64 system. > > The java version is: > openjdk version "1.8.0_121" > OpenJDK Runtime Environment (build > 1.8.0_121-8u121-b13-0ubuntu1.16.04.2-b13) > OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode) > > I used the steps in the section https://github.com/graalvm/graal-core#building-jvmci-jdk8 to build JVMCI JDK8. The build is successful, the last few lines of output is like: > make: Leaving directory '/pathto/Graal/graal-jvmci-8/make' > Compiling jdk.vm.ci.hotspot.amd64 with javac-daemon... [dependency > jdk.vm.ci.amd64 updated] Compiling jdk.vm.ci.hotspot.sparc with > javac-daemon... [dependency jdk.vm.ci.sparc updated] Compiling > jdk.vm.ci.hotspot.aarch64 with javac-daemon... [dependency > jdk.vm.ci.aarch64 updated] Archiving JVMCI_TEST... [dependency > jdk.vm.ci.runtime.test updated] Archiving JVM_PRODUCT_SERVER... > [dependency hotspot updated] Archiving JVMCI_HOTSPOT... [dependency > jdk.vm.ci.hotspot.aarch64 updated] > > And I update JAVA_HOME using > export JAVA_HOME=$(mx --java-home /usr/lib/jvm/java-8-openjdk-amd64 > jdkhome) > > echo $JAVA_HOME shows: > /pathto/Graal/graal-jvmci-8/jdk1.8.0_121/product > > Next I checkout graal-core and execute mx on it. > > The error seen is: > The VM does not support the minimum JVMCI API version required by Graal. > Cannot read JVMCI version from java.vm.version property: 25.121-b13. > Set the JVMCI_VERSION_CHECK environment variable to "ignore" to suppress this error or to "warn" to emit a warning and continue execution. > Currently used Java home directory is /usr/lib/jvm/java-8-openjdk-amd64/jre. > Currently used VM configuration is: OpenJDK 64-Bit Server VM Download > the latest JVMCI JDK 8 from > http://www.oracle.com/technetwork/oracle-labs/program-languages/downlo > ads/index.html > > Please suggest if I have missed out anything here. I do not want to download the built version of JVMCI because in parallel I am working on building it on PPC. It seems like your $JAVA_HOME env var has a problem otherwise mx should be picking up /pathto/Graal/graal-jvmci-8/jdk1.8.0_121/product not /usr/lib/jvm/java-8-openjdk-amd64/jre. Do you really have a root directory on your system named "pathto"? You can use the --java-home option to mx instead of JAVA_HOME: mx --java-home /pathto/Graal/graal-jvmci-8/jdk1.8.0_121/product ... -Doug DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. From deepali_patel at persistent.com Wed Mar 8 06:29:25 2017 From: deepali_patel at persistent.com (Deepali Patel) Date: Wed, 8 Mar 2017 06:29:25 +0000 Subject: Error while building JVMCI enabled JDK8 on Power In-Reply-To: References: <6B778C59-F1F2-4973-AD86-15C27C9EB335@oracle.com> Message-ID: Hello, I continued working on building JVMCI on PPC for Compiler2 only. Although I am now not getting error while building JVMCI JDK8, but the build is still not usable. While trying to use this JVMCI to compile graal-core I get the following error: ----------------- $:~/Graal/graal-core$ mx //clones truffle under ~/Graal/truffle //prints below error The VM does not support the minimum JVMCI API version required by Graal. Cannot read JVMCI version from java.vm.version property: 25.121-b13. Set the JVMCI_VERSION_CHECK environment variable to "ignore" to suppress this error or to "warn" to emit a warning and continue execution. Currently used Java home directory is /usr/lib/jvm/java-8-openjdk-ppc64el/jre. Currently used VM configuration is: OpenJDK 64-Bit Server VM Download the latest JVMCI JDK 8 from http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html ----------------- The investigation reveals that JVMCI is still not correctly built. I get the following errors for java -version: $:~/Graal/graal-jvmci-8/jdk1.8.0_121/product$ bin/java -version Error: dl failure on line 893 Error: failed ~/Graal/graal-jvmci-8/jdk1.8.0_121/product/jre/lib/ppc64le/server/libjvm.so, because ~/Graal/graal-jvmci-8/jdk1.8.0_121/product/jre/lib/ppc64le/server/libjvm.so: undefined symbol: _ZN13SharedRuntime15gen_i2c_adapterEP14MacroAssembleriiPK9BasicTypePK9VMRegPair The undefined method is - CodeInstaller::pd_relocate_poll(unsigned char*, int, Thread*) $:~/Graal/graal-jvmci-8/jdk1.8.0_121/product/jre/bin$ c++filt -n _ZN13CodeInstaller16pd_relocate_pollEPhiP6Thread CodeInstaller::pd_relocate_poll(unsigned char*, int, Thread*) Looks like this is due to the missing jvmciCodeInstaller_ppc.cpp. Any pointers on implementing this file would be of great help. Regards Deepali -----Original Message----- From: Christian Thalinger [mailto:cthalinger at twitter.com] Sent: Saturday, March 04, 2017 1:57 AM To: Deepali Patel Cc: Volker Simonis; graal-dev at openjdk.java.net Subject: Re: Error while building JVMCI enabled JDK8 on Power > On Mar 3, 2017, at 2:37 AM, Deepali Patel wrote: > > Hi, > > Thanks Thalinger and Volker for quick response. > > Do you think that it is possible to build JVMCI for COMPILER2 only instead of building it for both. Please advise. You mean build a VM with C2 only? Sure you can. > > Regards > Deepali > > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Thursday, March 02, 2017 11:16 PM > To: Christian Thalinger > Cc: Deepali Patel; graal-dev at openjdk.java.net > Subject: Re: Error while building JVMCI enabled JDK8 on Power > > No, unfortunately not :( > We're currently totally overloaded with Java 9 so we won't have time for JVMCI/Graal until after we've released that. > > Regards, > Volker > > > On Thu, Mar 2, 2017 at 6:20 PM, Christian Thalinger wrote: >> You should talk to some of the SAP people. Volker, has anyone at SAP thought or even done some work on JVMCI for PPC? >> >>> On Mar 2, 2017, at 2:17 AM, Deepali Patel wrote: >>> >>> Hello Doug and Gilles, >>> >>> I have updated the arch to ppc64le. >>> >>> Next, I see errors for missing c1_globals_ppc.hpp file. The src/cpu/x86/vm directory contains this file for x86 and also contains many other files for C1. Looks like I will need all these files for PPC as well. However the corresponding directory - src/cpu/ppc/vm does not have these C1 files, although it does have 2 files for C2. Is there any specific reason due to which C1 implementation is not available for ppc or it is just unimplemented currently. Please advise. >>> >>> Regards >>> Deepali >>> -----Original Message----- >>> From: Deepali Patel >>> Sent: Tuesday, February 28, 2017 6:18 PM >>> To: 'Doug Simon' >>> Cc: Gilles Duboscq; graal-dev at openjdk.java.net >>> Subject: RE: Error while building JVMCI enabled JDK8 on Power >>> >>> Hi Doug, >>> >>> Thanks for helpful response. >>> >>> I have copied jvmci/jdk.vm.ci.amd64 and jvmci/jdk.vm.ci.hotspot.amd64 to create jvmci/jdk.vm.ci.ppc64 and jvmci/jdk.vm.ci.hotspot.ppc64 (as suggested by Gilles) respectively. I have modified the source code files to reflect ppc64 instead of amd64 in these folders. >>> >>> Then I realized that graal-jvmci-8/mx.jvmci/suite.py also needs to be updated to incorporate these new folders. I have also added ppc64le as the supported arch for the Distributions in graal-jvmci-8/mx.jvmci/suite.py. >>> >>> By default, the ppc64 is set as arch for LE versions as well, however this leads to following error. The jdk source code has jvm.cfg file under ppc64le folder: >>> mx --java-home /usr/lib/jvm/java-8-openjdk-ppc64el build >>> None >>> {'ppc64': {'path': 'build/product/linux/ppc64/server/jvm.tar'}, 'amd64': {'path': 'build/product/linux/amd64/server/jvm.tar'}, 'sparcv9': {'path': 'build/product/linux/sparcv9/server/jvm.tar'}} >>> Creating /home/deepali/Graal/graal-jvmci-8/jdk1.8.0_121/product >>> from /usr/lib/jvm/java-8-openjdk-ppc64el >>> >>> /home/deepali/Graal/graal-jvmci-8/jdk1.8.0_121/product/jre/lib/ppc64 >>> / >>> jvm.cfg does not exist >>> >>> Thus I think I need to update the arch to ppc64le in the makefiles. >>> >>> Another thing that I noticed is " WARNING: hsdis with flavor 'None' not supported on this plattform or architecture". So looks like I will need to port hsdis as well because it is not available for ppc at https://lafo.ssw.uni-linz.ac.at/pub/hsdis/. >>> >>> Regards >>> Deepali >>> >>> -----Original Message----- >>> From: Doug Simon [mailto:doug.simon at oracle.com] >>> Sent: Friday, February 24, 2017 2:48 PM >>> To: Deepali Patel >>> Cc: Gilles Duboscq; graal-dev at openjdk.java.net >>> Subject: Re: Error while building JVMCI enabled JDK8 on Power >>> >>> >>>> On 24 Feb 2017, at 09:20, Deepali Patel wrote: >>>> >>>> Thanks Doug and Gilles for quick response. >>>> >>>> Could you please throw some more light on the parts of code(folders, files etc) that will need to be updated/modified to get this working on PPC. Would we need assembly code as well? If so, could you please point me to the corresponding x86 files for reference. >>> >>> dsimon at kurz-3 ~/g/graal-jvmci-8> find src | grep jvmci | grep x86 >>> src/cpu/x86/vm/jvmci_globals_x86.hpp >>> src/cpu/x86/vm/jvmciCodeInstaller_x86.cpp >>> dsimon at kurz-3 ~/g/graal-jvmci-8> find src | grep jvmci | grep sparc >>> src/cpu/sparc/vm/jvmci_globals_sparc.hpp >>> src/cpu/sparc/vm/jvmciCodeInstaller_sparc.cpp >>> >>> dsimon at kurz-3 ~/g/graal-core> ls -d graal/*sparc* >>> graal/org.graalvm.compiler.asm.sparc graal/org.graalvm.compiler.core.sparc.test graal/org.graalvm.compiler.replacements.sparc >>> graal/org.graalvm.compiler.asm.sparc.test graal/org.graalvm.compiler.hotspot.sparc graal/org.graalvm.compiler.truffle.hotspot.sparc >>> graal/org.graalvm.compiler.core.sparc graal/org.graalvm.compiler.lir.sparc >>> dsimon at kurz-3 ~/g/graal-core> ls -d graal/*amd64* >>> graal/org.graalvm.compiler.asm.amd64 graal/org.graalvm.compiler.core.amd64.test graal/org.graalvm.compiler.lir.amd64 >>> graal/org.graalvm.compiler.asm.amd64.test graal/org.graalvm.compiler.hotspot.amd64 graal/org.graalvm.compiler.replacements.amd64 >>> graal/org.graalvm.compiler.core.amd64 graal/org.graalvm.compiler.hotspot.amd64.test graal/org.graalvm.compiler.truffle.hotspot.amd64 >>> >>> Hope that helps, >>> >>> -Doug >>> >>>> -----Original Message----- >>>> From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On >>>> Behalf Of Gilles Duboscq >>>> Sent: Thursday, February 23, 2017 5:02 PM >>>> To: graal-dev at openjdk.java.net >>>> Subject: Re: Error while building JVMCI enabled JDK8 on Power >>>> >>>> You will also need to implement the Java side of things. >>>> See for example the sources in jvmci/jdk.vm.ci.amd64 and jvmci/jdk.vm.ci.hotspot.amd64. >>>> >>>> Gilles >>>> >>>> On 23/02/17 11:26, Doug Simon wrote: >>>>> Hi Deepali, >>>>> >>>>> This is an interesting but non-trivial project I suspect. You will need to look at all the machine specific JVMCI files and create corresponding *_ppc.[hpp|cpp] files. The existing jvmciGlobals_ppc.hpp needs to be renamed to jvmci_globals_ppc.hpp (as you observed) and completed as part of this. >>>>> >>>>> -Doug >>>>> >>>>>> On 23 Feb 2017, at 10:41, Deepali Patel wrote: >>>>>> >>>>>> Hello Team, >>>>>> >>>>>> I am trying to build Graal core on Power. >>>>>> >>>>>> >>>>>> 1. I have updated mx.py to allow build on Power: >>>>>> ----------------- >>>>>> diff --git a/mx.py b/mx.py >>>>>> index 172609d..de932f6 100755 >>>>>> --- a/mx.py >>>>>> +++ b/mx.py >>>>>> @@ -7369,6 +7369,8 @@ def get_arch(): >>>>>> except OSError: >>>>>> # sysctl is not available >>>>>> pass >>>>>> + if machine == 'ppc64le' and get_os() == 'linux': >>>>>> + return 'ppc64le' >>>>>> abort('unknown or unsupported architecture: os=' + get_os() + ', >>>>>> machine=' + machine) >>>>>> >>>>>> mx_subst.results_substitutions.register_no_arg('arch', get_arch) >>>>>> ------------------------------ >>>>>> >>>>>> >>>>>> 2. Next I am trying to build building JVMCI enabled JDK8. However, I see following error: >>>>>> >>>>>> Generating precompiled header precompiled.hpp.gch >>>>>> >>>>>> In file included from /pathto/allocation.hpp:28:0, >>>>>> >>>>>> from /pathto/iterator.hpp:28, >>>>>> >>>>>> from /pathto/genOopClosures.hpp:28, >>>>>> >>>>>> from /pathto/klass.hpp:28, >>>>>> >>>>>> from /pathto/handles.hpp:28, >>>>>> >>>>>> from /pathto/universe.hpp:28, >>>>>> >>>>>> from /pathto/oopRecorder.hpp:28, >>>>>> >>>>>> from /pathto/codeBuffer.hpp:28, >>>>>> >>>>>> from /pathto/assembler.hpp:28, >>>>>> >>>>>> from /pathto/precompiled.hpp:29: >>>>>> >>>>>> /pathto/globals.hpp:143:34: fatal error: jvmci_globals_ppc.hpp: >>>>>> No such file or directory >>>>>> >>>>>> compilation terminated. >>>>>> >>>>>> /pathto/vm.make:322: recipe for target 'precompiled.hpp.gch' >>>>>> failed >>>>>> >>>>>> make[4]: Leaving directory '/pathto/linux_ppc64_compiler2/product' >>>>>> >>>>>> make[4]: *** [precompiled.hpp.gch] Error 1 >>>>>> >>>>>> /pathto/top.make:119: recipe for target 'the_vm' failed >>>>>> >>>>>> make[3]: Leaving directory '/pathto/product' >>>>>> >>>>>> /pathto/make/linux/Makefile:303: recipe for target 'product' >>>>>> failed >>>>>> >>>>>> make[2]: Leaving directory '/pathto/graal-jvmci-8/build/linux' >>>>>> >>>>>> Makefile:231: recipe for target 'generic_build2' failed >>>>>> >>>>>> make[1]: Leaving directory '/pathtoGraal/graal-jvmci-8/make' >>>>>> >>>>>> make[3]: *** [the_vm] Error 2 >>>>>> >>>>>> make[2]: *** [product] Error 2 >>>>>> >>>>>> make[1]: *** [generic_build2] Error 2 >>>>>> >>>>>> Makefile:182: recipe for target 'product' failed >>>>>> >>>>>> make: *** [product] Error 2 >>>>>> >>>>>> make: Leaving directory '/pathto/graal-jvmci-8/make' >>>>>> >>>>>> Building HotSpot[product, server] failed >>>>>> >>>>>> 1 build tasks failed >>>>>> >>>>>> >>>>>> >>>>>> 3. I dont see jvmci_globals_ppc.hpp in the src tree. But there is another file with name jvmciGlobals_ppc.hpp available in the src tree. I tried to use jvmciGlobals_ppc.hpp, but I get following errors: >>>>>> >>>>>> /pathto/graal-jvmci-8/src/cpu/ppc/vm/jvmciGlobals_ppc.hpp:35:2: >>>>>> error: #error Unimplemented >>>>>> >>>>>> #error Unimplemented >>>>>> >>>>>> ^ >>>>>> >>>>>> /pathto/graal-jvmci-8/make/linux/makefiles/vm.make:322: recipe >>>>>> for target 'precompiled.hpp.gch' failed >>>>>> >>>>>> Please advise if I am missing on something here. >>>>>> >>>>>> Regards >>>>>> Deepali >>>>>> >>>>>> >>>>>> >>>>>> DISCLAIMER >>>>>> ========== >>>>>> This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. >>>>>> >>>>> >>>> >>>> DISCLAIMER >>>> ========== >>>> This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. >>>> >>> >>> >>> DISCLAIMER >>> ========== >>> This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. >>> >> > > DISCLAIMER > ========== > This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. > DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. From doug.simon at oracle.com Wed Mar 8 08:46:05 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 8 Mar 2017 09:46:05 +0100 Subject: Error while building JVMCI enabled JDK8 on Power In-Reply-To: References: <6B778C59-F1F2-4973-AD86-15C27C9EB335@oracle.com> Message-ID: <302186A4-B2F1-4D2A-A955-3634CD2F68BB@oracle.com> > On 8 Mar 2017, at 07:29, Deepali Patel wrote: > > Hello, > > I continued working on building JVMCI on PPC for Compiler2 only. > Although I am now not getting error while building JVMCI JDK8, but the build is still not usable. > > While trying to use this JVMCI to compile graal-core I get the following error: > ----------------- > $:~/Graal/graal-core$ mx > //clones truffle under ~/Graal/truffle > //prints below error > The VM does not support the minimum JVMCI API version required by Graal. > Cannot read JVMCI version from java.vm.version property: 25.121-b13. > Set the JVMCI_VERSION_CHECK environment variable to "ignore" to suppress this error or to "warn" to emit a warning and continue execution. > Currently used Java home directory is /usr/lib/jvm/java-8-openjdk-ppc64el/jre. > Currently used VM configuration is: OpenJDK 64-Bit Server VM > Download the latest JVMCI JDK 8 from http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html > ----------------- > > The investigation reveals that JVMCI is still not correctly built. I get the following errors for java -version: > $:~/Graal/graal-jvmci-8/jdk1.8.0_121/product$ bin/java -version > Error: dl failure on line 893 > Error: failed ~/Graal/graal-jvmci-8/jdk1.8.0_121/product/jre/lib/ppc64le/server/libjvm.so, because ~/Graal/graal-jvmci-8/jdk1.8.0_121/product/jre/lib/ppc64le/server/libjvm.so: undefined symbol: _ZN13SharedRuntime15gen_i2c_adapterEP14MacroAssembleriiPK9BasicTypePK9VMRegPair > > The undefined method is - CodeInstaller::pd_relocate_poll(unsigned char*, int, Thread*) > $:~/Graal/graal-jvmci-8/jdk1.8.0_121/product/jre/bin$ c++filt -n _ZN13CodeInstaller16pd_relocate_pollEPhiP6Thread > CodeInstaller::pd_relocate_poll(unsigned char*, int, Thread*) > > Looks like this is due to the missing jvmciCodeInstaller_ppc.cpp. Any pointers on implementing this file would be of great help. Look at src/cpu/sparc/vm/jvmciCodeInstaller_sparc.cpp and src/cpu/x86/vm/jvmciCodeInstaller_x86.cpp. Without a more specific question, it's hard to help. -Doug From aph at redhat.com Wed Mar 8 08:46:43 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 8 Mar 2017 08:46:43 +0000 Subject: Error while building JVMCI enabled JDK8 on Power In-Reply-To: References: <6B778C59-F1F2-4973-AD86-15C27C9EB335@oracle.com> Message-ID: <281a7ac4-c206-ac66-374a-b3e8056c2d3e@redhat.com> On 08/03/17 06:29, Deepali Patel wrote: > Looks like this is due to the missing > jvmciCodeInstaller_ppc.cpp. Any pointers on implementing this file > would be of great help. You have to write it. There are examples for x86 and AArch64. You need to make a PowerPC version. What other kinds of help do you need? Perhaps it's not obvious, but to port JVMCI you'll need a detailed knowledge of the PowerPC HotSpot port. Andrew. From deepali_patel at persistent.com Wed Mar 8 09:24:12 2017 From: deepali_patel at persistent.com (Deepali Patel) Date: Wed, 8 Mar 2017 09:24:12 +0000 Subject: Error while building JVMCI enabled JDK8 on Power In-Reply-To: <281a7ac4-c206-ac66-374a-b3e8056c2d3e@redhat.com> References: <6B778C59-F1F2-4973-AD86-15C27C9EB335@oracle.com> <281a7ac4-c206-ac66-374a-b3e8056c2d3e@redhat.com> Message-ID: Thanks Andrew and Doug for helpful responses. Yes correct, I needed to ask what knowledge would I need to implement the PowerPC version other than the existing samples. And now I know that it is "PowerPC HotSpot port". Thanks Andrew. Would it be possible to point to any links or documentation on Hotspot Porting? On another note I observed the following on https://en.wikipedia.org/wiki/HotSpot "Porting HotSpot is difficult because the code, while written in mostly C++, contains much assembly language.[17] To remedy this, the IcedTea project has developed a generic port of the HotSpot interpreter called zero-assembler Hotspot (or zero), with almost no assembly code. This port is intended for easy adaptation of the interpreter component of HotSpot to any Linux processor architecture. The code of zero-assembler Hotspot is used for all the non-x86 architecture ports of HotSpot (PowerPC, Itanium (IA-64), S390 and ARM) since version 1.6" So do you think that zero-assembler could be helpful in my case. Please advise. Regards Deepali -----Original Message----- From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Andrew Haley Sent: Wednesday, March 08, 2017 2:17 PM To: graal-dev at openjdk.java.net Subject: Re: Error while building JVMCI enabled JDK8 on Power On 08/03/17 06:29, Deepali Patel wrote: > Looks like this is due to the missing > jvmciCodeInstaller_ppc.cpp. Any pointers on implementing this file > would be of great help. You have to write it. There are examples for x86 and AArch64. You need to make a PowerPC version. What other kinds of help do you need? Perhaps it's not obvious, but to port JVMCI you'll need a detailed knowledge of the PowerPC HotSpot port. Andrew. DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. From aph at redhat.com Wed Mar 8 09:40:54 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 8 Mar 2017 09:40:54 +0000 Subject: Error while building JVMCI enabled JDK8 on Power In-Reply-To: References: <6B778C59-F1F2-4973-AD86-15C27C9EB335@oracle.com> <281a7ac4-c206-ac66-374a-b3e8056c2d3e@redhat.com> Message-ID: <669759b8-16de-0670-034e-d7369c8621ac@redhat.com> On 08/03/17 09:24, Deepali Patel wrote: > Would it be possible to point to any links or documentation on Hotspot Porting? I've never seen any. I read the source code and learned. It took a long time. > So do you think that zero-assembler could be helpful in my case. Please advise. I'm certain that Zero is not appropriate for this. Let's back up for a moment. What do you want to achieve as a result of this work? Andrew. From deepali_patel at persistent.com Wed Mar 8 09:48:00 2017 From: deepali_patel at persistent.com (Deepali Patel) Date: Wed, 8 Mar 2017 09:48:00 +0000 Subject: Error while building JVMCI enabled JDK8 on Power In-Reply-To: <669759b8-16de-0670-034e-d7369c8621ac@redhat.com> References: <6B778C59-F1F2-4973-AD86-15C27C9EB335@oracle.com> <281a7ac4-c206-ac66-374a-b3e8056c2d3e@redhat.com> <669759b8-16de-0670-034e-d7369c8621ac@redhat.com> Message-ID: Hi Andrew, The intent is to port Graal compiler to PPC. Regards Deepali -----Original Message----- From: Andrew Haley [mailto:aph at redhat.com] Sent: Wednesday, March 08, 2017 3:11 PM To: Deepali Patel; graal-dev at openjdk.java.net Subject: Re: Error while building JVMCI enabled JDK8 on Power On 08/03/17 09:24, Deepali Patel wrote: > Would it be possible to point to any links or documentation on Hotspot Porting? I've never seen any. I read the source code and learned. It took a long time. > So do you think that zero-assembler could be helpful in my case. Please advise. I'm certain that Zero is not appropriate for this. Let's back up for a moment. What do you want to achieve as a result of this work? Andrew. DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. From aph at redhat.com Wed Mar 8 09:52:29 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 8 Mar 2017 09:52:29 +0000 Subject: Error while building JVMCI enabled JDK8 on Power In-Reply-To: References: <6B778C59-F1F2-4973-AD86-15C27C9EB335@oracle.com> <281a7ac4-c206-ac66-374a-b3e8056c2d3e@redhat.com> <669759b8-16de-0670-034e-d7369c8621ac@redhat.com> Message-ID: <6ede4304-ba9a-6029-c817-7e00e11b7d42@redhat.com> On 08/03/17 09:48, Deepali Patel wrote: > The intent is to port Graal compiler to PPC. So, there is no substitute for study and experimentation. I'd start by choosing a port that is supported by JVMCI and then studying it. I'd immediately use GDB to step through the CodeInstaller and see how it patches the instructions, and then imitate that . Andrew. From adinn at redhat.com Mon Mar 20 08:43:16 2017 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 20 Mar 2017 08:43:16 +0000 Subject: RFR: AArch64: Implementing address lowering to make use of immediate address mode In-Reply-To: <58BDF15D.5060901@oracle.com> References: <206f2ccf-7e37-1b7b-3f30-7b319ddb6534@redhat.com> <58B61837.60107@oracle.com> <68ee82f2-c230-76de-b6bc-88ada8a73e85@redhat.com> <58BDF15D.5060901@oracle.com> Message-ID: Hi Tom, Thanks for the advice and apologies for not replying sooner -- I have been chasing a very nasty bug in the (non-graal) jdk8u x86 JVM code for the last few weeks. I'll attempt to follow your advice and write an alternative lowering phase for use by AArch64. However, I'd also like to see if there is a better approach that either postpones lowering or, at least, unifies it for the different architectures. I'll let you know of progress on both fronts as/when available. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander On 06/03/17 23:31, Tom Rodriguez wrote: > > > Andrew Dinn wrote: >> Hi Tom, >> >> >> On 01/03/17 00:39, Tom Rodriguez wrote: >>> There's nothing about the AddressLoweringPhase that says the mapping of >>> old the OffsetAddressNode to machine dependent address mode must be one >>> to one. You are free to examine the usages and generate a distinct >>> address node for each use. GVN will common any duplicates back >>> together. You still will need to select the right forms for the backend >>> so it doesn't address all the problems you mention. >> >> Thanks very much for replying. I'm not quite sure I follow what you are >> saying but let me try to confirm that I am on the right track. >> >> I do understand that each usage of some given OffsetAddress can be >> substituted /per usage/ by an appropriate AArch64AddressNode without >> fear of introducing unnecessary replicas. The thrust of your comment >> seems to be that my current patch doesn't actually need to detect a >> single, unique LIRKind for all usages in order to be able to embed a >> constant index as displacement. It could instead traverse all usages >> and, where possible, replace the OffsetAddress referenced from the usage >> with a lowered AddressNode employing a displacement constructed >> according to the LIRKind of that usage. >> >> Is that what you are suggesting? > > Yes. > >> If so then I agree that I might perhaps >> be able tweak the patch to do this. However, that's really somewhat >> incidental to the concerns I originally raised, perhaps even providing >> an a fortiori argument for addressing them. The AddressLowering phase is >> given an AddressNode to lower, a node which may be shared by multiple >> usages. It is not given a usage (i.e. a node using the AddressNode) and >> asked whether it wants to provide a lowered address node specific to >> that usage. >> >> So, the problem remains that the lowering model AddressLowering has >> adopted is based on a misguided notion that lowering can be scheduled >> per AddressNode without reference to usage. I really want to try to fix >> the model not the current patch. > > Well the model was adequate for the platforms we supported at the time > which is why I think it was chosen. The current > AddressLoweringPhase/AddressLowering logic is simple enough that I'm not > sure it really makes sense to make it complex just to support AArch64. > I'd probably just write a custom phase to do what needs to be done, and > factor out the creation of the address lowering phase in > HotSpotSuitesProvider so that an AArch64HotSpotSuitesProvider could > provide it's own completely custom implementation. I'd probably > directly pass in the required AArch64HotSpotLIRKindTool as well which > you can just construct by hand. It could that the the kind tool should > be part of the HotSpotProviders instead of buried in the LIRGenerator > but it hasn't needed to be more visible until now. It seems like you > would have everything required for proper code generation then. > >> >> If your point is that AddressLowering ought, perhaps, to be rewritten to >> operate by considering each usage in turn then that would indeed be a >> better model. >> >> Apologies if I am barking up the wrong tree entirely here and have not >> grasped what you are getting at. >> >> Of course, m comments about the need to have access to the usage kind >> (and, hence, to a KindTool) and my failure to understand how a derived >> LIRKind should be computed for any lowered AddressNode also still stand >> in the hope of some comment or explanation which would, of course, be >> gratefully received. > > As far as the LIRKind of an AddressValue most of the time it is actually > completely unused. The purpose of the derived information is for > tracking when a pointer into the middle of a Java object has been > materialized as a value so that it can be described to the garbage > collector or for error checking that a derived value isn't live across a > safepoint. The LIRKind of an AddressValue is the LIRKind of the address > as a computation but the LIRKind of the memory operation is LIRKind of > the datum being transferred so they are only loosely related. So the > only case where the LIRKind of an address value will ever appear as a > value is for an LEA style operation. > > I suspect I haven't addressed all your concerns about the LIRKind for > addresses so please follow up with any clarifying questions. > > tom > >> >> regards, >> >> >> Andrew Dinn >> ----------- >> >>> Andrew Dinn wrote: >>>> I have patched (a slightly out of date version of) Graal to allow >>>> AArch64 to make use of scaled and unscaled immediate addressing. This >>>> generates much better code but the implementation is 'wrong' in several >>>> important respects. A pull request including the change is available >>>> here >>>> >>>> https://github.com/graalvm/graal-core/pull/258 >>>> >>>> I have no wish for this change to be included as is - I posted it >>>> merely >>>> to enable discussion of what is really needed. >>>> >>>> The patch deliberately bypasses the normal AddressLowering phase (I'll >>>> explain why in a second). Instead it intercepts translation of >>>> addresses >>>> during the generate phase. Basically, it attempts to improve addresses >>>> initially generated as an OffsetAddress (i.e. supplied with 2 Values, >>>> base and index) when the index is an integer constant whcih can be >>>> embedded as an immediate displacement (I guess it ought to handle the >>>> reverse case where base is a constant and index a general Value but >>>> nothing appears to be generating addresses with constants in that >>>> order). It does so by 'nulling' the index saving the constant as a >>>> displacement and resetting the addressing mode from register offset to >>>> scaled or unscaled immediate. >>>> >>>> So, before applying the patch addresses with constant index were >>>> 'improved' by replacing the constant node with a constant load and >>>> relying on the use of register_offset addressing mode to do the actual >>>> memory operation. The result is code like this: >>>> >>>> movz x3, #0xc # constant load of offset value >>>> movk x3, #0x0, lsl #16 >>>> ldr w1 [x2, x3] # (1) load via register_offset addressing >>>> >>>> The patch tries instead to transform the node to use either scaled or >>>> unscaled immediate addressing resulting, respectively, in code like >>>> this: >>>> >>>> ldr w1, [x2,#12] # (2) load via scaled immediate addressing >>>> >>>> or (let's assume we had a negative offset mandating an unscaled load) >>>> >>>> ldr w1, [x2, #-12] # (3) load via unscaled immediate >>>> addressing >>>> >>>> There are two related reasons why this has been done in the Generate >>>> phase rather than in the AddressLowering phase. I present them both in >>>> turn below in order to pose some questions about why AddressLowering is >>>> currently done as is and to suggest what might be needed to fix it. >>>> >>>> I have also include a critique of the way a derived LIRKind is computed >>>> for the AddressValue returned by method generate(). I am unclear why it >>>> is currently being computed as is and also unclear what would be an >>>> appropriate derived value when immediates are encoded. Advice or >>>> comments regarding the patch and the following critique would be very >>>> welcome. >>>> >>>> Scaling depends on the transfer size >>>> ------------------------------------ >>>> >>>> The first problem is that for scaled memory addressing the decision as >>>> to whether or not a given constant index can be embedded as an >>>> immediate >>>> constant in the address node depends upon how the address is used by >>>> one >>>> or more memory ops. >>>> >>>> In code example (2) which uses scaled addressing above the load >>>> instruction is transferring a 32 bit datum (as indicated in the >>>> assembly >>>> code by the target register being named w1). The load address is the 64 >>>> bit value in r1 (as indicated in the assembly code by the base register >>>> being named x1) plus constant offset 12. >>>> >>>> A scaled immediate memory op can embed a 12 bit unsigned displacement. >>>> However, the unit size for the embedded value is determined by the size >>>> of the accessed datum. So, for a 32 bit load/store the set of offsets >>>> which are valid is {4, 8, ... 4 * (2^12 - 1)}. For a byte load the set >>>> of valid offsets is {1, 2, ... (2^12-1)}. >>>> >>>> Obviously, as the name clearly indicates, there is no dependency on >>>> transfer size when using unscaled addressing. Memory ops employing this >>>> latter addressing may embed any signed 9-bit displacement which is >>>> always counted in a unit size of bytes. So, translation to use unscaled >>>> addressing in the AddressLowering phase doesn't present any great >>>> problem. However, generating the best code requires implementing both >>>> modes. >>>> >>>> The upshot is that in order to determine whether a constant index >>>> can be >>>> replaced by an immediate node the lowering code needs to investigate >>>> usages of the address node and establish that all usages employ a >>>> unique >>>> transfer size. >>>> >>>> As you can see in the pull request, the patch includes a method >>>> getUsageSize() which does that job. It traverses all usages and returns >>>> either a single platform kind which defines a transfer size common to >>>> all usages or null if no such unique common kind exists. This leads to >>>> the second problem. (n.b. I have finessed Prefetch usages for now >>>> because the current AArch64 Graal does not generate code for prefetch. >>>> That will need fixing when it is implemented). >>>> >>>> Identification of the platform kind requires a generator >>>> -------------------------------------------------------- >>>> >>>> The above requirement explains why the lowering code is implemented as >>>> part of the Generate phase instead of in the AddressLowering phase. >>>> Identifying the PlatformKind associated with a specific usage of the >>>> AddressNode requires translating the stamp of each usage to an LIRKind. >>>> That mandates availability of a suitable instance of LIRKindTool >>>> (actually an AArch64LIRKindTool) which parameterizes the call to >>>> getUsageSize(). The KindTool must be obtained from the >>>> AArch64LIRGenerator tool which is obtained form the NodeLIRBuilderTool >>>> passed to the AArch64AddressNode generate() method. >>>> >>>> I don't doubt that here is some sneaky way of ensuring that the >>>> AArch64AddressLowering instance obtains access to an >>>> AArch64LIRGenerator >>>> (and, thence, an AArch64LIRKindTool) behind the scenes. However, >>>> implementing a solution like that does not really seem to me to be the >>>> correct solution. There is an assumption in the current code that >>>> address lowering can be done prior to the Generate phase without >>>> needing >>>> to identify whatever transfer datum and/or transfer size is at stake >>>> when the address is being used. That's a broken assumption and I would >>>> prefer to fix it. >>>> >>>> One solution would be to have the generic code precompute the common >>>> usage LIRKind and pass it to the implementation class which extends >>>> AddressLowering. Alternatively, the abstract parent class could provide >>>> a convenience method allowing a suitable PlatformKind to be computed. >>>> Either way this means that the parent needs to know about the Arch and >>>> know how to obtain an arch-specific KindTool. I'm happy to look into >>>> proposing a solution along these lines but I'd like to canvas here for >>>> comments before doing so. >>>> >>>> Another alternative would be to perform address lowering at a later >>>> stage, perhaps in the back end even. This would perhaps require doing >>>> some of the transforms done in e.g. AMD64AddressLowering as generic >>>> transforms and having a generic AddressNode which allowed for a >>>> non-constant index and/or constant displacement. I'm also happy to >>>> consider how this might work but I'd probably need more advice about >>>> how >>>> to go about this. >>>> >>>> >>>> The LIRKind of the resulting AddressValue -- is it correct? >>>> ----------------------------------------------------------- >>>> >>>> The patch in the pull request attempts to follow the logic of the >>>> preceding code in deriving an LIRKind for whatever AddressNode it >>>> constructs, whether using register offset or immediate addressing. >>>> However, I am not sure what the original logic is. >>>> >>>> In the original code for AArch64AddressNode.generate() the case where >>>> the either base or index was null is treated by setting, respectively, >>>> baseValue or indexValue to Value.ILLEGAL. Later in that original code >>>> this implies that indexReference is also set to Value.ILLEGAL. The >>>> LIRKind for the final resulting AArch64AddressValue is computed by >>>> executing >>>> >>>> LIRKind kind = LIRKind.combineDerived(tool.getLIRKind(stamp()), >>>> baseReference, >>>> indexReference); >>>> >>>> So, when base is, say, a register and index is null this represents a >>>> direct reference through a register with no offset. I would have >>>> expected that in this circumstance there was some coherent way of >>>> deriving the LIRKind of the address from the LIRKind associated with >>>> base. However, because index is null, so indexValue is Value.ILLEGAL >>>> and >>>> hence indexReference is also Value.ILLEGAL. combineDerived handles this >>>> case by returning an unknown reference derived from the stamp(). By >>>> contrast, if indexReference was null then combineDerived would compute >>>> the combined reference by calling makeDerivedReference(base). >>>> >>>> My patch follows this code by starting off with indexValue = null then >>>> resetting it to Value.ILLEGAL either if it is null or if it is possible >>>> to intervene and replace a constant index with a displacement. >>>> Otherwise, when we have a non-null index, indexValue is computed as >>>> before by executing >>>> >>>> indexValue = tool.asAllocatable(gen.operand(index)); >>>> >>>> I have also preserved the original special case processing for >>>> AddressingMode.IMMEDIATE_UNSCALED where the indexReference is >>>> derived by >>>> executing >>>> >>>> indexReference = LIRKind.derivedBaseFromValue(indexValue); >>>> >>>> although I'll note that in cases where that addressing mode is >>>> introduced by replacing a constant index with an unscaled displacement >>>> indexValue will be Value.ILLEGAL and hence the indexReference will be >>>> returned as Value.ILLEGAL which seems to negate the purpose of that >>>> special case handling. >>>> >>>> I am suspicious that all of this computation seems to be rather >>>> redundant anyway. At the point of use of an Address to encode a Load or >>>> Store (or possibly a Prefetch) the LIRKind of the address appears to be >>>> ignored and instead the LIRKind of the transfer datum is used to >>>> generate the load. Is this computation of the derived actually >>>> achieving >>>> anything important? >>>> >>>> regards, >>>> >>>> >>>> Andrew Dinn >>>> ----------- >>>> Senior Principal Software Engineer >>>> Red Hat UK Ltd >>>> Registered in England and Wales under Company Registration No. 03798903 >>>> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From thomas.wuerthinger at oracle.com Mon Mar 20 10:42:27 2017 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Mon, 20 Mar 2017 11:42:27 +0100 Subject: RFR: AArch64: Implementing address lowering to make use of immediate address mode In-Reply-To: References: <206f2ccf-7e37-1b7b-3f30-7b319ddb6534@redhat.com> <58B61837.60107@oracle.com> <68ee82f2-c230-76de-b6bc-88ada8a73e85@redhat.com> <58BDF15D.5060901@oracle.com> Message-ID: Make sure to be on the latest version. A few days ago the address lowering phase was moved to be after the new fix reads phase. Means no need to deal with pi nodes. - thomas > On 20 Mar 2017, at 09:43, Andrew Dinn wrote: > > Hi Tom, > > Thanks for the advice and apologies for not replying sooner -- I have > been chasing a very nasty bug in the (non-graal) jdk8u x86 JVM code for > the last few weeks. > > I'll attempt to follow your advice and write an alternative lowering > phase for use by AArch64. However, I'd also like to see if there is a > better approach that either postpones lowering or, at least, unifies it > for the different architectures. I'll let you know of progress on both > fronts as/when available. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > >> On 06/03/17 23:31, Tom Rodriguez wrote: >> >> >> Andrew Dinn wrote: >>> Hi Tom, >>> >>> >>>> On 01/03/17 00:39, Tom Rodriguez wrote: >>>> There's nothing about the AddressLoweringPhase that says the mapping of >>>> old the OffsetAddressNode to machine dependent address mode must be one >>>> to one. You are free to examine the usages and generate a distinct >>>> address node for each use. GVN will common any duplicates back >>>> together. You still will need to select the right forms for the backend >>>> so it doesn't address all the problems you mention. >>> >>> Thanks very much for replying. I'm not quite sure I follow what you are >>> saying but let me try to confirm that I am on the right track. >>> >>> I do understand that each usage of some given OffsetAddress can be >>> substituted /per usage/ by an appropriate AArch64AddressNode without >>> fear of introducing unnecessary replicas. The thrust of your comment >>> seems to be that my current patch doesn't actually need to detect a >>> single, unique LIRKind for all usages in order to be able to embed a >>> constant index as displacement. It could instead traverse all usages >>> and, where possible, replace the OffsetAddress referenced from the usage >>> with a lowered AddressNode employing a displacement constructed >>> according to the LIRKind of that usage. >>> >>> Is that what you are suggesting? >> >> Yes. >> >>> If so then I agree that I might perhaps >>> be able tweak the patch to do this. However, that's really somewhat >>> incidental to the concerns I originally raised, perhaps even providing >>> an a fortiori argument for addressing them. The AddressLowering phase is >>> given an AddressNode to lower, a node which may be shared by multiple >>> usages. It is not given a usage (i.e. a node using the AddressNode) and >>> asked whether it wants to provide a lowered address node specific to >>> that usage. >>> >>> So, the problem remains that the lowering model AddressLowering has >>> adopted is based on a misguided notion that lowering can be scheduled >>> per AddressNode without reference to usage. I really want to try to fix >>> the model not the current patch. >> >> Well the model was adequate for the platforms we supported at the time >> which is why I think it was chosen. The current >> AddressLoweringPhase/AddressLowering logic is simple enough that I'm not >> sure it really makes sense to make it complex just to support AArch64. >> I'd probably just write a custom phase to do what needs to be done, and >> factor out the creation of the address lowering phase in >> HotSpotSuitesProvider so that an AArch64HotSpotSuitesProvider could >> provide it's own completely custom implementation. I'd probably >> directly pass in the required AArch64HotSpotLIRKindTool as well which >> you can just construct by hand. It could that the the kind tool should >> be part of the HotSpotProviders instead of buried in the LIRGenerator >> but it hasn't needed to be more visible until now. It seems like you >> would have everything required for proper code generation then. >> >>> >>> If your point is that AddressLowering ought, perhaps, to be rewritten to >>> operate by considering each usage in turn then that would indeed be a >>> better model. >>> >>> Apologies if I am barking up the wrong tree entirely here and have not >>> grasped what you are getting at. >>> >>> Of course, m comments about the need to have access to the usage kind >>> (and, hence, to a KindTool) and my failure to understand how a derived >>> LIRKind should be computed for any lowered AddressNode also still stand >>> in the hope of some comment or explanation which would, of course, be >>> gratefully received. >> >> As far as the LIRKind of an AddressValue most of the time it is actually >> completely unused. The purpose of the derived information is for >> tracking when a pointer into the middle of a Java object has been >> materialized as a value so that it can be described to the garbage >> collector or for error checking that a derived value isn't live across a >> safepoint. The LIRKind of an AddressValue is the LIRKind of the address >> as a computation but the LIRKind of the memory operation is LIRKind of >> the datum being transferred so they are only loosely related. So the >> only case where the LIRKind of an address value will ever appear as a >> value is for an LEA style operation. >> >> I suspect I haven't addressed all your concerns about the LIRKind for >> addresses so please follow up with any clarifying questions. >> >> tom >> >>> >>> regards, >>> >>> >>> Andrew Dinn >>> ----------- >>> >>>> Andrew Dinn wrote: >>>>> I have patched (a slightly out of date version of) Graal to allow >>>>> AArch64 to make use of scaled and unscaled immediate addressing. This >>>>> generates much better code but the implementation is 'wrong' in several >>>>> important respects. A pull request including the change is available >>>>> here >>>>> >>>>> https://github.com/graalvm/graal-core/pull/258 >>>>> >>>>> I have no wish for this change to be included as is - I posted it >>>>> merely >>>>> to enable discussion of what is really needed. >>>>> >>>>> The patch deliberately bypasses the normal AddressLowering phase (I'll >>>>> explain why in a second). Instead it intercepts translation of >>>>> addresses >>>>> during the generate phase. Basically, it attempts to improve addresses >>>>> initially generated as an OffsetAddress (i.e. supplied with 2 Values, >>>>> base and index) when the index is an integer constant whcih can be >>>>> embedded as an immediate displacement (I guess it ought to handle the >>>>> reverse case where base is a constant and index a general Value but >>>>> nothing appears to be generating addresses with constants in that >>>>> order). It does so by 'nulling' the index saving the constant as a >>>>> displacement and resetting the addressing mode from register offset to >>>>> scaled or unscaled immediate. >>>>> >>>>> So, before applying the patch addresses with constant index were >>>>> 'improved' by replacing the constant node with a constant load and >>>>> relying on the use of register_offset addressing mode to do the actual >>>>> memory operation. The result is code like this: >>>>> >>>>> movz x3, #0xc # constant load of offset value >>>>> movk x3, #0x0, lsl #16 >>>>> ldr w1 [x2, x3] # (1) load via register_offset addressing >>>>> >>>>> The patch tries instead to transform the node to use either scaled or >>>>> unscaled immediate addressing resulting, respectively, in code like >>>>> this: >>>>> >>>>> ldr w1, [x2,#12] # (2) load via scaled immediate addressing >>>>> >>>>> or (let's assume we had a negative offset mandating an unscaled load) >>>>> >>>>> ldr w1, [x2, #-12] # (3) load via unscaled immediate >>>>> addressing >>>>> >>>>> There are two related reasons why this has been done in the Generate >>>>> phase rather than in the AddressLowering phase. I present them both in >>>>> turn below in order to pose some questions about why AddressLowering is >>>>> currently done as is and to suggest what might be needed to fix it. >>>>> >>>>> I have also include a critique of the way a derived LIRKind is computed >>>>> for the AddressValue returned by method generate(). I am unclear why it >>>>> is currently being computed as is and also unclear what would be an >>>>> appropriate derived value when immediates are encoded. Advice or >>>>> comments regarding the patch and the following critique would be very >>>>> welcome. >>>>> >>>>> Scaling depends on the transfer size >>>>> ------------------------------------ >>>>> >>>>> The first problem is that for scaled memory addressing the decision as >>>>> to whether or not a given constant index can be embedded as an >>>>> immediate >>>>> constant in the address node depends upon how the address is used by >>>>> one >>>>> or more memory ops. >>>>> >>>>> In code example (2) which uses scaled addressing above the load >>>>> instruction is transferring a 32 bit datum (as indicated in the >>>>> assembly >>>>> code by the target register being named w1). The load address is the 64 >>>>> bit value in r1 (as indicated in the assembly code by the base register >>>>> being named x1) plus constant offset 12. >>>>> >>>>> A scaled immediate memory op can embed a 12 bit unsigned displacement. >>>>> However, the unit size for the embedded value is determined by the size >>>>> of the accessed datum. So, for a 32 bit load/store the set of offsets >>>>> which are valid is {4, 8, ... 4 * (2^12 - 1)}. For a byte load the set >>>>> of valid offsets is {1, 2, ... (2^12-1)}. >>>>> >>>>> Obviously, as the name clearly indicates, there is no dependency on >>>>> transfer size when using unscaled addressing. Memory ops employing this >>>>> latter addressing may embed any signed 9-bit displacement which is >>>>> always counted in a unit size of bytes. So, translation to use unscaled >>>>> addressing in the AddressLowering phase doesn't present any great >>>>> problem. However, generating the best code requires implementing both >>>>> modes. >>>>> >>>>> The upshot is that in order to determine whether a constant index >>>>> can be >>>>> replaced by an immediate node the lowering code needs to investigate >>>>> usages of the address node and establish that all usages employ a >>>>> unique >>>>> transfer size. >>>>> >>>>> As you can see in the pull request, the patch includes a method >>>>> getUsageSize() which does that job. It traverses all usages and returns >>>>> either a single platform kind which defines a transfer size common to >>>>> all usages or null if no such unique common kind exists. This leads to >>>>> the second problem. (n.b. I have finessed Prefetch usages for now >>>>> because the current AArch64 Graal does not generate code for prefetch. >>>>> That will need fixing when it is implemented). >>>>> >>>>> Identification of the platform kind requires a generator >>>>> -------------------------------------------------------- >>>>> >>>>> The above requirement explains why the lowering code is implemented as >>>>> part of the Generate phase instead of in the AddressLowering phase. >>>>> Identifying the PlatformKind associated with a specific usage of the >>>>> AddressNode requires translating the stamp of each usage to an LIRKind. >>>>> That mandates availability of a suitable instance of LIRKindTool >>>>> (actually an AArch64LIRKindTool) which parameterizes the call to >>>>> getUsageSize(). The KindTool must be obtained from the >>>>> AArch64LIRGenerator tool which is obtained form the NodeLIRBuilderTool >>>>> passed to the AArch64AddressNode generate() method. >>>>> >>>>> I don't doubt that here is some sneaky way of ensuring that the >>>>> AArch64AddressLowering instance obtains access to an >>>>> AArch64LIRGenerator >>>>> (and, thence, an AArch64LIRKindTool) behind the scenes. However, >>>>> implementing a solution like that does not really seem to me to be the >>>>> correct solution. There is an assumption in the current code that >>>>> address lowering can be done prior to the Generate phase without >>>>> needing >>>>> to identify whatever transfer datum and/or transfer size is at stake >>>>> when the address is being used. That's a broken assumption and I would >>>>> prefer to fix it. >>>>> >>>>> One solution would be to have the generic code precompute the common >>>>> usage LIRKind and pass it to the implementation class which extends >>>>> AddressLowering. Alternatively, the abstract parent class could provide >>>>> a convenience method allowing a suitable PlatformKind to be computed. >>>>> Either way this means that the parent needs to know about the Arch and >>>>> know how to obtain an arch-specific KindTool. I'm happy to look into >>>>> proposing a solution along these lines but I'd like to canvas here for >>>>> comments before doing so. >>>>> >>>>> Another alternative would be to perform address lowering at a later >>>>> stage, perhaps in the back end even. This would perhaps require doing >>>>> some of the transforms done in e.g. AMD64AddressLowering as generic >>>>> transforms and having a generic AddressNode which allowed for a >>>>> non-constant index and/or constant displacement. I'm also happy to >>>>> consider how this might work but I'd probably need more advice about >>>>> how >>>>> to go about this. >>>>> >>>>> >>>>> The LIRKind of the resulting AddressValue -- is it correct? >>>>> ----------------------------------------------------------- >>>>> >>>>> The patch in the pull request attempts to follow the logic of the >>>>> preceding code in deriving an LIRKind for whatever AddressNode it >>>>> constructs, whether using register offset or immediate addressing. >>>>> However, I am not sure what the original logic is. >>>>> >>>>> In the original code for AArch64AddressNode.generate() the case where >>>>> the either base or index was null is treated by setting, respectively, >>>>> baseValue or indexValue to Value.ILLEGAL. Later in that original code >>>>> this implies that indexReference is also set to Value.ILLEGAL. The >>>>> LIRKind for the final resulting AArch64AddressValue is computed by >>>>> executing >>>>> >>>>> LIRKind kind = LIRKind.combineDerived(tool.getLIRKind(stamp()), >>>>> baseReference, >>>>> indexReference); >>>>> >>>>> So, when base is, say, a register and index is null this represents a >>>>> direct reference through a register with no offset. I would have >>>>> expected that in this circumstance there was some coherent way of >>>>> deriving the LIRKind of the address from the LIRKind associated with >>>>> base. However, because index is null, so indexValue is Value.ILLEGAL >>>>> and >>>>> hence indexReference is also Value.ILLEGAL. combineDerived handles this >>>>> case by returning an unknown reference derived from the stamp(). By >>>>> contrast, if indexReference was null then combineDerived would compute >>>>> the combined reference by calling makeDerivedReference(base). >>>>> >>>>> My patch follows this code by starting off with indexValue = null then >>>>> resetting it to Value.ILLEGAL either if it is null or if it is possible >>>>> to intervene and replace a constant index with a displacement. >>>>> Otherwise, when we have a non-null index, indexValue is computed as >>>>> before by executing >>>>> >>>>> indexValue = tool.asAllocatable(gen.operand(index)); >>>>> >>>>> I have also preserved the original special case processing for >>>>> AddressingMode.IMMEDIATE_UNSCALED where the indexReference is >>>>> derived by >>>>> executing >>>>> >>>>> indexReference = LIRKind.derivedBaseFromValue(indexValue); >>>>> >>>>> although I'll note that in cases where that addressing mode is >>>>> introduced by replacing a constant index with an unscaled displacement >>>>> indexValue will be Value.ILLEGAL and hence the indexReference will be >>>>> returned as Value.ILLEGAL which seems to negate the purpose of that >>>>> special case handling. >>>>> >>>>> I am suspicious that all of this computation seems to be rather >>>>> redundant anyway. At the point of use of an Address to encode a Load or >>>>> Store (or possibly a Prefetch) the LIRKind of the address appears to be >>>>> ignored and instead the LIRKind of the transfer datum is used to >>>>> generate the load. Is this computation of the derived actually >>>>> achieving >>>>> anything important? >>>>> >>>>> regards, >>>>> >>>>> >>>>> Andrew Dinn >>>>> ----------- >>>>> Senior Principal Software Engineer >>>>> Red Hat UK Ltd >>>>> Registered in England and Wales under Company Registration No. 03798903 >>>>> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander >> From adinn at redhat.com Mon Mar 20 16:40:51 2017 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 20 Mar 2017 16:40:51 +0000 Subject: Problem with broken build (was Re: RFR: AArch64: Implementing address lowering to make use of immediate address mode In-Reply-To: References: <206f2ccf-7e37-1b7b-3f30-7b319ddb6534@redhat.com> <58B61837.60107@oracle.com> <68ee82f2-c230-76de-b6bc-88ada8a73e85@redhat.com> <58BDF15D.5060901@oracle.com> Message-ID: <2b83dcd0-f54e-df1e-9627-e5e6c6171b80@redhat.com> On 20/03/17 10:42, Thomas Wuerthinger wrote: > Make sure to be on the latest version. A few days ago the address > lowering phase was moved to be after the new fix reads phase. Means > no need to deal with pi nodes. Well, that sounds like a good idea. However, I appear to be snookered because of an incompatibility introduced between graal and truffle (see log output after signature). It seems that the following recent change to class GraalTVMCI () added methods cloneUninitialized and isCloneUninitializedSupported which indirect to super class TVMCI: commit 7d9581a3f0a82ff7d5e9a9eb03642d1eb12b0dc2 Author: Christian Humer Date: Wed Feb 15 14:15:30 2017 +0100 Use TMVCI to access isCloneUnitializedSupported and cloneUnitialized I have run 'mx supdate' but the source for class TVMCI in the truffle tree does not include these methods. Did someone forget to update the graal tree to specify a new truffle repo version dependency? Or am I supposed to do that by hand? e.g. by pulling the mos up to date truffle tree? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- $ JVMCI_VERSION_CHECK=ignore mx --java-home ~/openjdk/jdk9/build/linux-aarch64-normal-server-release/images/jdk build . . . Compiling org.graalvm.compiler.loop.test with javac-daemon... [dependency org.graalvm.compiler.loop updated] /home/adinn/openjdk/graal/graal-core/graal/org.graalvm.compiler.truffle/src/org/graalvm/compiler/truffle/GraalTVMCI.java:77: error: method does not override or implement a method from a supertype @Override ^ /home/adinn/openjdk/graal/graal-core/graal/org.graalvm.compiler.truffle/src/org/graalvm/compiler/truffle/GraalTVMCI.java:79: error: cannot find symbol return super.cloneUninitialized(root); ^ symbol: method cloneUninitialized(RootNode) /home/adinn/openjdk/graal/graal-core/graal/org.graalvm.compiler.truffle/src/org/graalvm/compiler/truffle/GraalTVMCI.java:82: error: method does not override or implement a method from a supertype @Override ^ /home/adinn/openjdk/graal/graal-core/graal/org.graalvm.compiler.truffle/src/org/graalvm/compiler/truffle/GraalTVMCI.java:84: error: cannot find symbol return super.isCloneUninitializedSupported(root); ^ symbol: method isCloneUninitializedSupported(RootNode) . . . 4 errors Compiling org.graalvm.compiler.truffle with javac-daemon failed 1 build tasks failed From gilles.m.duboscq at oracle.com Mon Mar 20 16:50:26 2017 From: gilles.m.duboscq at oracle.com (Gilles Duboscq) Date: Mon, 20 Mar 2017 17:50:26 +0100 Subject: Problem with broken build (was Re: RFR: AArch64: Implementing address lowering to make use of immediate address mode In-Reply-To: <2b83dcd0-f54e-df1e-9627-e5e6c6171b80@redhat.com> References: <206f2ccf-7e37-1b7b-3f30-7b319ddb6534@redhat.com> <58B61837.60107@oracle.com> <68ee82f2-c230-76de-b6bc-88ada8a73e85@redhat.com> <58BDF15D.5060901@oracle.com> <2b83dcd0-f54e-df1e-9627-e5e6c6171b80@redhat.com> Message-ID: Hi Andrew, mx supdate does not pull in any new changes, it just goes to tip/branch head in all repos. mx sforceimports makes sure that all repos are at the version specified in the suite.py files, pull new changes in if necessary. Gilles On 20/03/17 17:40, Andrew Dinn wrote: > On 20/03/17 10:42, Thomas Wuerthinger wrote: >> Make sure to be on the latest version. A few days ago the address >> lowering phase was moved to be after the new fix reads phase. Means >> no need to deal with pi nodes. > > Well, that sounds like a good idea. However, I appear to be snookered > because of an incompatibility introduced between graal and truffle (see > log output after signature). > > It seems that the following recent change to class GraalTVMCI () added > methods cloneUninitialized and isCloneUninitializedSupported which > indirect to super class TVMCI: > > commit 7d9581a3f0a82ff7d5e9a9eb03642d1eb12b0dc2 > Author: Christian Humer > Date: Wed Feb 15 14:15:30 2017 +0100 > > Use TMVCI to access isCloneUnitializedSupported and cloneUnitialized > > > I have run 'mx supdate' but the source for class TVMCI in the truffle > tree does not include these methods. Did someone forget to update the > graal tree to specify a new truffle repo version dependency? Or am I > supposed to do that by hand? e.g. by pulling the mos up to date truffle > tree? > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > > ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- > > $ JVMCI_VERSION_CHECK=ignore mx --java-home > ~/openjdk/jdk9/build/linux-aarch64-normal-server-release/images/jdk build > . . . > Compiling org.graalvm.compiler.loop.test with javac-daemon... > [dependency org.graalvm.compiler.loop updated] > /home/adinn/openjdk/graal/graal-core/graal/org.graalvm.compiler.truffle/src/org/graalvm/compiler/truffle/GraalTVMCI.java:77: > error: method does not override or implement a method from a supertype > @Override > ^ > /home/adinn/openjdk/graal/graal-core/graal/org.graalvm.compiler.truffle/src/org/graalvm/compiler/truffle/GraalTVMCI.java:79: > error: cannot find symbol > return super.cloneUninitialized(root); > ^ > symbol: method cloneUninitialized(RootNode) > /home/adinn/openjdk/graal/graal-core/graal/org.graalvm.compiler.truffle/src/org/graalvm/compiler/truffle/GraalTVMCI.java:82: > error: method does not override or implement a method from a supertype > @Override > ^ > /home/adinn/openjdk/graal/graal-core/graal/org.graalvm.compiler.truffle/src/org/graalvm/compiler/truffle/GraalTVMCI.java:84: > error: cannot find symbol > return super.isCloneUninitializedSupported(root); > ^ > symbol: method isCloneUninitializedSupported(RootNode) > . . . > 4 errors > Compiling org.graalvm.compiler.truffle with javac-daemon failed > 1 build tasks failed > From adinn at redhat.com Mon Mar 20 16:56:53 2017 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 20 Mar 2017 16:56:53 +0000 Subject: Problem with broken build (was Re: RFR: AArch64: Implementing address lowering to make use of immediate address mode In-Reply-To: References: <206f2ccf-7e37-1b7b-3f30-7b319ddb6534@redhat.com> <58B61837.60107@oracle.com> <68ee82f2-c230-76de-b6bc-88ada8a73e85@redhat.com> <58BDF15D.5060901@oracle.com> <2b83dcd0-f54e-df1e-9627-e5e6c6171b80@redhat.com> Message-ID: <7da73ef6-2ccf-5658-988d-866ce89a7014@redhat.com> Hi Gilles, On 20/03/17 16:50, Gilles Duboscq wrote: > mx supdate does not pull in any new changes, it just goes to > tip/branch head in all repos. > > mx sforceimports makes sure that all repos are at the version > specified in the suite.py files, pull new changes in if necessary. Ah, thank you for the very rapid response. mx sforceimports appears to have fixed things. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From jaroslav.tulach at oracle.com Thu Mar 23 05:46:55 2017 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Thu, 23 Mar 2017 06:46:55 +0100 Subject: Code sharing is in was: There are API changes in Truffle API! In-Reply-To: <1349805641.883.1490201301962@c8ffaf347c3f> References: <1349805641.883.1490201301962@c8ffaf347c3f> Message-ID: <10082267.2AH6cQ0ZfU@pracovni> Hi there. For last nine months I was struggling with code sharing. I tried many ways, but I couldn't get it to work properly. But yesterday was a great day: Christian Humer managed to merge his code sharing work. Congrats! I am so excited. The introduction of PolyglotRuntime gives us a chance to experiment with sharing of ASTs between different PolyglotEngines - something many language implementations wanted to play with. I am thrilled to gain some experience with the sharing and then think of proper ways to make it work in multi-language interop system as well. I hope you find Truffle code sharing support interesting too. -jt SignatureTest report Base version: Tested version: Check mode: bin [throws removed] Constant checking: on Added Classes ------------- com.oracle.truffle.api.TruffleLanguage$ContextReference com.oracle.truffle.api.nodes.LanguageInfo Added Nested Classes -------------------- com.oracle.truffle.api.TruffleLanguage: nested public final static com.oracle.truffle.api.TruffleLanguage$ContextReference Added Constructors ------------------ com.oracle.truffle.api.nodes.RootNode: constructor protected com.oracle.truffle.api.nodes.RootNode.init(com.oracle.truffle.api.TruffleLanguage) com.oracle.truffle.api.nodes.RootNode: constructor protected com.oracle.truffle.api.nodes.RootNode.init(com.oracle.truffle.api.TruffleLanguage,com.oracle.truffle.api.frame.FrameDescriptor) Added Methods ------------- com.oracle.truffle.api.TruffleLanguage: method public final com.oracle.truffle.api.TruffleLanguage$ContextReference com.oracle.truffle.api.TruffleLanguage.getContextReference() com.oracle.truffle.api.nodes.RootNode: method public final com.oracle.truffle.api.TruffleLanguage com.oracle.truffle.api.nodes.RootNode.getLanguage(java.lang.Class) com.oracle.truffle.api.nodes.RootNode: method public final com.oracle.truffle.api.nodes.LanguageInfo com.oracle.truffle.api.nodes.RootNode.getLanguageInfo() Added Annotations ----------------- com.oracle.truffle.api.ExecutionContext:anno 0 java.lang.Deprecated() com.oracle.truffle.api.TruffleLanguage.createFindContextNode: anno 0 java.lang.Deprecated() com.oracle.truffle.api.TruffleLanguage.findContext: anno 0 java.lang.Deprecated() com.oracle.truffle.api.nodes.Node.getLanguage: anno 0 java.lang.Deprecated() com.oracle.truffle.api.nodes.Node.getLanguage: anno 0 java.lang.Deprecated() com.oracle.truffle.api.nodes.Node.getLanguage: anno 0 java.lang.Deprecated() com.oracle.truffle.api.nodes.Node.getLanguage: anno 0 java.lang.Deprecated() com.oracle.truffle.api.nodes.Node.getLanguage: anno 0 java.lang.Deprecated() com.oracle.truffle.api.nodes.RootNode.getExecutionContext: anno 0 java.lang.Deprecated() com.oracle.truffle.api.nodes.RootNode.init: anno 0 java.lang.Deprecated() Added Annotations ----------------- com.oracle.truffle.api.nodes.Node.getLanguage: anno 0 java.lang.Deprecated() com.oracle.truffle.api.nodes.Node.getLanguage: anno 0 java.lang.Deprecated() Missing Methods --------------- com.oracle.truffle.api.interop.MessageResolution: method public abstract java.lang.Class com.oracle.truffle.api.interop.MessageResolution.language() Added Methods ------------- com.oracle.truffle.api.interop.MessageResolution: method public abstract !hasdefault java.lang.Class com.oracle.truffle.api.interop.MessageResolution.language() anno 0 java.lang.Deprecated() Added Annotations ----------------- com.oracle.truffle.api.interop.MessageResolution.language: anno 0 java.lang.Deprecated() Missing Superclasses or Superinterfaces --------------------------------------- com.oracle.truffle.api.vm.PolyglotEngine$Instrument: superclass java.lang.Object Added Classes ------------- com.oracle.truffle.api.vm.PolyglotRuntime com.oracle.truffle.api.vm.PolyglotRuntime$Builder com.oracle.truffle.api.vm.PolyglotRuntime$Instrument Added Superclasses or Superinterfaces ------------------------------------- com.oracle.truffle.api.vm.PolyglotEngine$Instrument: superclass com.oracle.truffle.api.vm.PolyglotRuntime$Instrument Added Methods ------------- com.oracle.truffle.api.vm.PolyglotEngine: method public com.oracle.truffle.api.vm.PolyglotRuntime com.oracle.truffle.api.vm.PolyglotEngine.getRuntime() com.oracle.truffle.api.vm.PolyglotEngine$Builder: method public com.oracle.truffle.api.vm.PolyglotEngine$Builder com.oracle.truffle.api.vm.PolyglotEngine $Builder.runtime(com.oracle.truffle.api.vm.PolyglotRuntime) com.oracle.truffle.api.vm.PolyglotEngine$Value: method public com.oracle.truffle.api.source.SourceSection com.oracle.truffle.api.vm.PolyglotEngine$Value.getSourceLocation() com.oracle.truffle.api.vm.PolyglotEngine$Value: method public com.oracle.truffle.api.vm.PolyglotEngine$Value com.oracle.truffle.api.vm.PolyglotEngine$Value.getMetaObject() Added Annotations ----------------- com.oracle.truffle.api.vm.PolyglotEngine$Instrument: anno 0 java.lang.Deprecated() com.oracle.truffle.api.vm.PolyglotEngine.getInstruments: anno 0 java.lang.Deprecated() From jaroslav.tulach at oracle.com Fri Mar 24 11:53:19 2017 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Fri, 24 Mar 2017 12:53:19 +0100 Subject: Code sharing is in In-Reply-To: <10082267.2AH6cQ0ZfU@pracovni> References: <1349805641.883.1490201301962@c8ffaf347c3f> <10082267.2AH6cQ0ZfU@pracovni> Message-ID: <10435096.2s64oAFRnl@pracovni> On ?tvrtek 23. b?ezna 2017 6:46:55 CET Jaroslav Tulach wrote: > Hi there. > For last nine months I was struggling with code sharing. I tried many ways, > but I couldn't get it to work properly. But yesterday was a great day: > Christian Humer managed to merge his code sharing work. Congrats! > > I am so excited. The introduction of PolyglotRuntime gives us a chance to > experiment with sharing of ASTs between different PolyglotEngines - > something many language implementations wanted to play with. I am thrilled > to gain some experience with the sharing and then think of proper ways to > make it work in multi-language interop system as well. > > I hope you find Truffle code sharing support interesting too. FYI: Javadoc for the new APIs for language integrators can be found at: http://graalvm.github.io/truffle/javadoc/com/oracle/truffle/api/vm/package-summary.html -jt > SignatureTest report > Base version: > Tested version: > Check mode: bin [throws removed] > Constant checking: on > > > Added Classes > ------------- > > com.oracle.truffle.api.TruffleLanguage$ContextReference > com.oracle.truffle.api.nodes.LanguageInfo > > Added Nested Classes > -------------------- > > com.oracle.truffle.api.TruffleLanguage: nested public final static > com.oracle.truffle.api.TruffleLanguage$ContextReference > > Added Constructors > ------------------ > > com.oracle.truffle.api.nodes.RootNode: constructor protected > com.oracle.truffle.api.nodes.RootNode.init(com.oracle.truffle.api.TruffleLan > guage) com.oracle.truffle.api.nodes.RootNode: constructor protected > com.oracle.truffle.api.nodes.RootNode.init(com.oracle.truffle.api.TruffleLan > guage,com.oracle.truffle.api.frame.FrameDescriptor) > > Added Methods > ------------- > > com.oracle.truffle.api.TruffleLanguage: method public final > com.oracle.truffle.api.TruffleLanguage$ContextReference > com.oracle.truffle.api.TruffleLanguage.getContextReference() > com.oracle.truffle.api.nodes.RootNode: method public final > com.oracle.truffle.api.TruffleLanguage > com.oracle.truffle.api.nodes.RootNode.getLanguage(java.lang.Class) > com.oracle.truffle.api.nodes.RootNode: method public final > com.oracle.truffle.api.nodes.LanguageInfo > com.oracle.truffle.api.nodes.RootNode.getLanguageInfo() > > Added Annotations > ----------------- > > com.oracle.truffle.api.ExecutionContext:anno 0 java.lang.Deprecated() > com.oracle.truffle.api.TruffleLanguage.createFindContextNode: > anno 0 java.lang.Deprecated() > com.oracle.truffle.api.TruffleLanguage.findContext: anno 0 > java.lang.Deprecated() > com.oracle.truffle.api.nodes.Node.getLanguage: anno 0 > java.lang.Deprecated() > com.oracle.truffle.api.nodes.Node.getLanguage: anno 0 > java.lang.Deprecated() > com.oracle.truffle.api.nodes.Node.getLanguage: anno 0 > java.lang.Deprecated() > com.oracle.truffle.api.nodes.Node.getLanguage: anno 0 > java.lang.Deprecated() > com.oracle.truffle.api.nodes.Node.getLanguage: anno 0 > java.lang.Deprecated() > com.oracle.truffle.api.nodes.RootNode.getExecutionContext: anno 0 > java.lang.Deprecated() > com.oracle.truffle.api.nodes.RootNode.init: anno 0 > java.lang.Deprecated() > > > > Added Annotations > ----------------- > > com.oracle.truffle.api.nodes.Node.getLanguage: anno 0 > java.lang.Deprecated() > com.oracle.truffle.api.nodes.Node.getLanguage: anno 0 > java.lang.Deprecated() > > > Missing Methods > --------------- > > com.oracle.truffle.api.interop.MessageResolution: method public > abstract java.lang.Class > com.oracle.truffle.api.interop.MessageResolution.language() > > Added Methods > ------------- > > com.oracle.truffle.api.interop.MessageResolution: method public > abstract !hasdefault java.lang.Class > com.oracle.truffle.api.interop.MessageResolution.language() > anno 0 java.lang.Deprecated() > > Added Annotations > ----------------- > > com.oracle.truffle.api.interop.MessageResolution.language: anno 0 > java.lang.Deprecated() > > Missing Superclasses or Superinterfaces > --------------------------------------- > > com.oracle.truffle.api.vm.PolyglotEngine$Instrument: superclass > java.lang.Object > > Added Classes > ------------- > > com.oracle.truffle.api.vm.PolyglotRuntime > com.oracle.truffle.api.vm.PolyglotRuntime$Builder > com.oracle.truffle.api.vm.PolyglotRuntime$Instrument > > Added Superclasses or Superinterfaces > ------------------------------------- > > com.oracle.truffle.api.vm.PolyglotEngine$Instrument: superclass > com.oracle.truffle.api.vm.PolyglotRuntime$Instrument > > Added Methods > ------------- > > com.oracle.truffle.api.vm.PolyglotEngine: method public > com.oracle.truffle.api.vm.PolyglotRuntime > com.oracle.truffle.api.vm.PolyglotEngine.getRuntime() > com.oracle.truffle.api.vm.PolyglotEngine$Builder: method public > com.oracle.truffle.api.vm.PolyglotEngine$Builder > com.oracle.truffle.api.vm.PolyglotEngine > $Builder.runtime(com.oracle.truffle.api.vm.PolyglotRuntime) > com.oracle.truffle.api.vm.PolyglotEngine$Value: method public > com.oracle.truffle.api.source.SourceSection > com.oracle.truffle.api.vm.PolyglotEngine$Value.getSourceLocation() > com.oracle.truffle.api.vm.PolyglotEngine$Value: method public > com.oracle.truffle.api.vm.PolyglotEngine$Value > com.oracle.truffle.api.vm.PolyglotEngine$Value.getMetaObject() > > Added Annotations > ----------------- > > com.oracle.truffle.api.vm.PolyglotEngine$Instrument: anno 0 > java.lang.Deprecated() > com.oracle.truffle.api.vm.PolyglotEngine.getInstruments: anno 0 > java.lang.Deprecated() From eregontp at gmail.com Fri Mar 24 13:41:44 2017 From: eregontp at gmail.com (Benoit Daloze) Date: Fri, 24 Mar 2017 14:41:44 +0100 Subject: Code sharing is in In-Reply-To: <10435096.2s64oAFRnl@pracovni> References: <1349805641.883.1490201301962@c8ffaf347c3f> <10082267.2AH6cQ0ZfU@pracovni> <10435096.2s64oAFRnl@pracovni> Message-ID: So how does one achieve code sharing? What "code" can be shared and how? On Fri, Mar 24, 2017 at 12:53 PM, Jaroslav Tulach < jaroslav.tulach at oracle.com> wrote: > On ?tvrtek 23. b?ezna 2017 6:46:55 CET Jaroslav Tulach wrote: > > Hi there. > > For last nine months I was struggling with code sharing. I tried many > ways, > > but I couldn't get it to work properly. But yesterday was a great day: > > Christian Humer managed to merge his code sharing work. Congrats! > > > > I am so excited. The introduction of PolyglotRuntime gives us a chance to > > experiment with sharing of ASTs between different PolyglotEngines - > > something many language implementations wanted to play with. I am > thrilled > > to gain some experience with the sharing and then think of proper ways to > > make it work in multi-language interop system as well. > > > > I hope you find Truffle code sharing support interesting too. > > FYI: Javadoc for the new APIs for language integrators can be found at: > http://graalvm.github.io/truffle/javadoc/com/oracle/ > truffle/api/vm/package-summary.html > > -jt > > > SignatureTest report > > Base version: > > Tested version: > > Check mode: bin [throws removed] > > Constant checking: on > > > > > > Added Classes > > ------------- > > > > com.oracle.truffle.api.TruffleLanguage$ContextReference > > com.oracle.truffle.api.nodes.LanguageInfo > > > > Added Nested Classes > > -------------------- > > > > com.oracle.truffle.api.TruffleLanguage: nested public final static > > com.oracle.truffle.api.TruffleLanguage$ContextReference > > > > Added Constructors > > ------------------ > > > > com.oracle.truffle.api.nodes.RootNode: constructor protected > > com.oracle.truffle.api.nodes.RootNode.init(com.oracle. > truffle.api.TruffleLan > > guage) com.oracle.truffle.api.nodes.RootNode: constructor protected > > com.oracle.truffle.api.nodes.RootNode.init(com.oracle. > truffle.api.TruffleLan > > guage,com.oracle.truffle.api.frame.FrameDescriptor) > > > > Added Methods > > ------------- > > > > com.oracle.truffle.api.TruffleLanguage: method public final > > com.oracle.truffle.api.TruffleLanguage$ContextReference > > com.oracle.truffle.api.TruffleLanguage.getContextReference() > > com.oracle.truffle.api.nodes.RootNode: method public final > > com.oracle.truffle.api.TruffleLanguage > > com.oracle.truffle.api.nodes.RootNode.getLanguage(java.lang.Class) > > com.oracle.truffle.api.nodes.RootNode: method public final > > com.oracle.truffle.api.nodes.LanguageInfo > > com.oracle.truffle.api.nodes.RootNode.getLanguageInfo() > > > > Added Annotations > > ----------------- > > > > com.oracle.truffle.api.ExecutionContext:anno 0 java.lang.Deprecated() > > com.oracle.truffle.api.TruffleLanguage.createFindContextNode: > > anno 0 java.lang.Deprecated() > > com.oracle.truffle.api.TruffleLanguage.findContext: anno 0 > > java.lang.Deprecated() > > com.oracle.truffle.api.nodes.Node.getLanguage: anno 0 > > java.lang.Deprecated() > > com.oracle.truffle.api.nodes.Node.getLanguage: anno 0 > > java.lang.Deprecated() > > com.oracle.truffle.api.nodes.Node.getLanguage: anno 0 > > java.lang.Deprecated() > > com.oracle.truffle.api.nodes.Node.getLanguage: anno 0 > > java.lang.Deprecated() > > com.oracle.truffle.api.nodes.Node.getLanguage: anno 0 > > java.lang.Deprecated() > > com.oracle.truffle.api.nodes.RootNode.getExecutionContext: anno 0 > > java.lang.Deprecated() > > com.oracle.truffle.api.nodes.RootNode.init: anno 0 > > java.lang.Deprecated() > > > > > > > > Added Annotations > > ----------------- > > > > com.oracle.truffle.api.nodes.Node.getLanguage: anno 0 > > java.lang.Deprecated() > > com.oracle.truffle.api.nodes.Node.getLanguage: anno 0 > > java.lang.Deprecated() > > > > > > Missing Methods > > --------------- > > > > com.oracle.truffle.api.interop.MessageResolution: method > public > > abstract java.lang.Class > > com.oracle.truffle.api.interop.MessageResolution.language() > > > > Added Methods > > ------------- > > > > com.oracle.truffle.api.interop.MessageResolution: method > public > > abstract !hasdefault java.lang.Class > > com.oracle.truffle.api.interop.MessageResolution.language() > > anno 0 java.lang.Deprecated() > > > > Added Annotations > > ----------------- > > > > com.oracle.truffle.api.interop.MessageResolution.language: anno 0 > > java.lang.Deprecated() > > > > Missing Superclasses or Superinterfaces > > --------------------------------------- > > > > com.oracle.truffle.api.vm.PolyglotEngine$Instrument: superclass > > java.lang.Object > > > > Added Classes > > ------------- > > > > com.oracle.truffle.api.vm.PolyglotRuntime > > com.oracle.truffle.api.vm.PolyglotRuntime$Builder > > com.oracle.truffle.api.vm.PolyglotRuntime$Instrument > > > > Added Superclasses or Superinterfaces > > ------------------------------------- > > > > com.oracle.truffle.api.vm.PolyglotEngine$Instrument: superclass > > com.oracle.truffle.api.vm.PolyglotRuntime$Instrument > > > > Added Methods > > ------------- > > > > com.oracle.truffle.api.vm.PolyglotEngine: method > public > > com.oracle.truffle.api.vm.PolyglotRuntime > > com.oracle.truffle.api.vm.PolyglotEngine.getRuntime() > > com.oracle.truffle.api.vm.PolyglotEngine$Builder: method > public > > com.oracle.truffle.api.vm.PolyglotEngine$Builder > > com.oracle.truffle.api.vm.PolyglotEngine > > $Builder.runtime(com.oracle.truffle.api.vm.PolyglotRuntime) > > com.oracle.truffle.api.vm.PolyglotEngine$Value: method > public > > com.oracle.truffle.api.source.SourceSection > > com.oracle.truffle.api.vm.PolyglotEngine$Value.getSourceLocation() > > com.oracle.truffle.api.vm.PolyglotEngine$Value: method > public > > com.oracle.truffle.api.vm.PolyglotEngine$Value > > com.oracle.truffle.api.vm.PolyglotEngine$Value.getMetaObject() > > > > Added Annotations > > ----------------- > > > > com.oracle.truffle.api.vm.PolyglotEngine$Instrument: anno 0 > > java.lang.Deprecated() > > com.oracle.truffle.api.vm.PolyglotEngine.getInstruments: anno 0 > > java.lang.Deprecated() > > > From jaroslav.tulach at oracle.com Mon Mar 27 08:19:01 2017 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Mon, 27 Mar 2017 10:19:01 +0200 Subject: Code sharing is in In-Reply-To: References: <1349805641.883.1490201301962@c8ffaf347c3f> <10435096.2s64oAFRnl@pracovni> Message-ID: <8027017.dYAdpnX21V@pracovni> On p?tek 24. b?ezna 2017 14:41:44 CEST Benoit Daloze wrote: > So how does one achieve code sharing? > What "code" can be shared and how? Hello Benoit, we still don't have a tutorial for language implementor's except the extra- ordinary videos: http://graalvm.github.io/truffle/javadoc/com/oracle/truffle/tutorial/newlanguage/ package-summary.html We only document various bits and pieces in a class/method Javadoc. For example the http://graalvm.github.io/truffle/javadoc/com/oracle/truffle/api/vm/ PolyglotRuntime.html has a reference to http://graalvm.github.io/truffle/javadoc/com/oracle/truffle/api/TruffleLanguage.html which now contains sentences like: - A new language implementation instance is instantiated for each runtime that is created using the runtime builder. - Global state can be shared between multiple context instances by saving them as a field of the TruffleLanguage subclass I know, it isn't much, but hopefully enough to get you started. -jt PS: Feel free to report a bug if some of existing info is wrong or misleading. > > On Fri, Mar 24, 2017 at 12:53 PM, Jaroslav Tulach < > > jaroslav.tulach at oracle.com> wrote: > > On ?tvrtek 23. b?ezna 2017 6:46:55 CET Jaroslav Tulach wrote: > > > Hi there. > > > For last nine months I was struggling with code sharing. I tried many > > > > ways, > > > > > but I couldn't get it to work properly. But yesterday was a great day: > > > Christian Humer managed to merge his code sharing work. Congrats! > > > > > > I am so excited. The introduction of PolyglotRuntime gives us a chance > > > to > > > experiment with sharing of ASTs between different PolyglotEngines - > > > something many language implementations wanted to play with. I am > > > > thrilled > > > > > to gain some experience with the sharing and then think of proper ways > > > to > > > make it work in multi-language interop system as well. > > > > > > I hope you find Truffle code sharing support interesting too. > > > > FYI: Javadoc for the new APIs for language integrators can be found at: > > http://graalvm.github.io/truffle/javadoc/com/oracle/ > > truffle/api/vm/package-summary.html > > > > -jt > > > > > SignatureTest report > > > Base version: > > > Tested version: > > > Check mode: bin [throws removed] > > > Constant checking: on > > > > > > > > > Added Classes > > > ------------- > > > > > > com.oracle.truffle.api.TruffleLanguage$ContextReference > > > com.oracle.truffle.api.nodes.LanguageInfo > > > > > > Added Nested Classes > > > -------------------- > > > > > > com.oracle.truffle.api.TruffleLanguage: nested public final static > > > com.oracle.truffle.api.TruffleLanguage$ContextReference > > > > > > Added Constructors > > > ------------------ > > > > > > com.oracle.truffle.api.nodes.RootNode: constructor protected > > > com.oracle.truffle.api.nodes.RootNode.init(com.oracle. > > > > truffle.api.TruffleLan > > > > > guage) com.oracle.truffle.api.nodes.RootNode: constructor protected > > > com.oracle.truffle.api.nodes.RootNode.init(com.oracle. > > > > truffle.api.TruffleLan > > > > > guage,com.oracle.truffle.api.frame.FrameDescriptor) > > > > > > Added Methods > > > ------------- > > > > > > com.oracle.truffle.api.TruffleLanguage: method public final > > > com.oracle.truffle.api.TruffleLanguage$ContextReference > > > com.oracle.truffle.api.TruffleLanguage.getContextReference() > > > com.oracle.truffle.api.nodes.RootNode: method public final > > > com.oracle.truffle.api.TruffleLanguage > > > com.oracle.truffle.api.nodes.RootNode.getLanguage(java.lang.Class) > > > com.oracle.truffle.api.nodes.RootNode: method public final > > > com.oracle.truffle.api.nodes.LanguageInfo > > > com.oracle.truffle.api.nodes.RootNode.getLanguageInfo() > > > > > > Added Annotations > > > ----------------- > > > > > > com.oracle.truffle.api.ExecutionContext:anno 0 java.lang.Deprecated() > > > com.oracle.truffle.api.TruffleLanguage.createFindContextNode: > > > anno 0 java.lang.Deprecated() > > > com.oracle.truffle.api.TruffleLanguage.findContext: anno 0 > > > java.lang.Deprecated() > > > com.oracle.truffle.api.nodes.Node.getLanguage: anno 0 > > > java.lang.Deprecated() > > > com.oracle.truffle.api.nodes.Node.getLanguage: anno 0 > > > java.lang.Deprecated() > > > com.oracle.truffle.api.nodes.Node.getLanguage: anno 0 > > > java.lang.Deprecated() > > > com.oracle.truffle.api.nodes.Node.getLanguage: anno 0 > > > java.lang.Deprecated() > > > com.oracle.truffle.api.nodes.Node.getLanguage: anno 0 > > > java.lang.Deprecated() > > > com.oracle.truffle.api.nodes.RootNode.getExecutionContext: anno 0 > > > java.lang.Deprecated() > > > com.oracle.truffle.api.nodes.RootNode.init: anno 0 > > > java.lang.Deprecated() > > > > > > > > > > > > Added Annotations > > > ----------------- > > > > > > com.oracle.truffle.api.nodes.Node.getLanguage: anno 0 > > > java.lang.Deprecated() > > > com.oracle.truffle.api.nodes.Node.getLanguage: anno 0 > > > java.lang.Deprecated() > > > > > > > > > Missing Methods > > > --------------- > > > > > > com.oracle.truffle.api.interop.MessageResolution: method > > > > public > > > > > abstract java.lang.Class > > > com.oracle.truffle.api.interop.MessageResolution.language() > > > > > > Added Methods > > > ------------- > > > > > > com.oracle.truffle.api.interop.MessageResolution: method > > > > public > > > > > abstract !hasdefault java.lang.Class > > > com.oracle.truffle.api.interop.MessageResolution.language() > > > > > > anno 0 java.lang.Deprecated() > > > > > > Added Annotations > > > ----------------- > > > > > > com.oracle.truffle.api.interop.MessageResolution.language: anno 0 > > > java.lang.Deprecated() > > > > > > Missing Superclasses or Superinterfaces > > > --------------------------------------- > > > > > > com.oracle.truffle.api.vm.PolyglotEngine$Instrument: superclass > > > java.lang.Object > > > > > > Added Classes > > > ------------- > > > > > > com.oracle.truffle.api.vm.PolyglotRuntime > > > com.oracle.truffle.api.vm.PolyglotRuntime$Builder > > > com.oracle.truffle.api.vm.PolyglotRuntime$Instrument > > > > > > Added Superclasses or Superinterfaces > > > ------------------------------------- > > > > > > com.oracle.truffle.api.vm.PolyglotEngine$Instrument: superclass > > > com.oracle.truffle.api.vm.PolyglotRuntime$Instrument > > > > > > Added Methods > > > ------------- > > > > > > com.oracle.truffle.api.vm.PolyglotEngine: method > > > > public > > > > > com.oracle.truffle.api.vm.PolyglotRuntime > > > com.oracle.truffle.api.vm.PolyglotEngine.getRuntime() > > > com.oracle.truffle.api.vm.PolyglotEngine$Builder: method > > > > public > > > > > com.oracle.truffle.api.vm.PolyglotEngine$Builder > > > com.oracle.truffle.api.vm.PolyglotEngine > > > $Builder.runtime(com.oracle.truffle.api.vm.PolyglotRuntime) > > > com.oracle.truffle.api.vm.PolyglotEngine$Value: method > > > > public > > > > > com.oracle.truffle.api.source.SourceSection > > > com.oracle.truffle.api.vm.PolyglotEngine$Value.getSourceLocation() > > > com.oracle.truffle.api.vm.PolyglotEngine$Value: method > > > > public > > > > > com.oracle.truffle.api.vm.PolyglotEngine$Value > > > com.oracle.truffle.api.vm.PolyglotEngine$Value.getMetaObject() > > > > > > Added Annotations > > > ----------------- > > > > > > com.oracle.truffle.api.vm.PolyglotEngine$Instrument: anno 0 > > > java.lang.Deprecated() > > > com.oracle.truffle.api.vm.PolyglotEngine.getInstruments: anno 0 > > > java.lang.Deprecated() From michael.c.berg at intel.com Thu Mar 30 18:23:56 2017 From: michael.c.berg at intel.com (Berg, Michael C) Date: Thu, 30 Mar 2017 18:23:56 +0000 Subject: code review for loop splitting code Message-ID: This modification splits simple loops into pre/main/post loops with main loop entry tests which use array length to compare with the maximal trip value to prevent iterations which require bounds checks from being executed in the main loop. Some merge work will be done to bring in the enterprise version of range check elimination. Both phases will be posed in mid tier. This work stages the introduction and implementation loop unrolling, which will also occur on simple loops which do not have range checks. Data flow/state relationships are managed in this code to maintain values defined in the pre/main/post loops. The code is available as: https://github.com/graalvm/graal-core/pull/264 For review. Regards, Michael From java at stefan-marr.de Fri Mar 31 11:16:50 2017 From: java at stefan-marr.de (Stefan Marr) Date: Fri, 31 Mar 2017 13:16:50 +0200 Subject: Test Interface for Truffle: Good for PE tests? Message-ID: <27E450E8-8339-4F39-AF54-56B1DBE6A897@stefan-marr.de> Hi: I just saw that a recent commit [1] introduced a test interface for Truffle. What exactly is this good for? Can I use this to easily check for instance that specific operations properly constant fold? I looked a little at the documentation. Does the warmup annotation imply that after the given number of iterations, compilation is forced for me? This isn?t quite clear to me from the javadoc. If this can be used to build checks that code constant folds, I am also wondering how the tests can be ignored/skipped when unit tests are executed without Graal. Are there now facilities, to test explicitly that the TruffleRuntime supports compilation? There has been a long standing feature request for such an API [2]. Thanks Stefan [1]: https://github.com/graalvm/truffle/commit/1dce7adb2833abc2aa3f3a4bcd0e0c288a472faf [2]: https://github.com/graalvm/truffle/issues/47 -- Stefan Marr Johannes Kepler Universit?t Linz http://stefan-marr.de/research/