From adinn at redhat.com Mon Apr 3 11:37:34 2017 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 3 Apr 2017 12:37:34 +0100 Subject: RFR: Implement better address lowering for AArch64 Message-ID: The following pull request includes changes to improve address lowering for AArch64. https://github.com/graalvm/graal-core/pull/266 I would be grateful for review and feedback and, if acceptbale, a pull to the main repo. Purpose ------- The point of this change is to allow AArch64 addresses to be converted to use either index or displacement mode (n.b. index and displacement cannot be combined on AArch64). This requires a different approach to AMD64/SPARC because the suitability of a displacement for embedding in a load/store instruction depends on the nature of that usage (specifically, the transfer size for the datum affects the decision as to whether a given displacement can be embedded). A secondary part of the change is to implement address improvement during lowering to allow certain patterns of address combination to be simplified. Implementation -------------- The basic change is to provide a new phase AddressLoweringByUsePhase which schedules addresses to an address lowering implementation per use, providing it with the ability to take the use into account when doing the lowering. AArch64 provides a callback class AArch64AddressLoweringByUse which implements this phase. This replaces the previous lowering callback AArch64AddressLowering which has been deleted. It includes optimization of certain nested address combinations as per the other address lowering implementations (there are less such opportunities for AArch64). Making use of the new phase also requires modifying the HotSpotSuiteProvider classes which previously configured the AddressLoweringPhase used by AMD64, SPARC and AArch64. A superclass HotSpotSuiteProviderBase has been factored out of the original class HotSpotSuiteProvider making it a subclass specific to AMD64 and SPARC. An alternative subclass, AArch64HotSpotSuiteProvider, has been provided for AArch64. The two subclasses perform almost all their work by delegating to the super class. They only differ in how they configure address lowering. The step which previously added an AddressLoweringPhase to the low tier is now performed in each subclass. HotSpotSuiteProvider configures an AddressLoweringPhase while AArch64HotSpotSuiteProvider configures an AddressLoweringByUsePhase. Testing ------- I have run several small Java programs. I have eyeballed the generated code for these programs and for JDK runtime methods to verify that address lowering is being done correctly. 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 doug.simon at oracle.com Mon Apr 3 12:30:29 2017 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 3 Apr 2017 14:30:29 +0200 Subject: RFR: Implement better address lowering for AArch64 In-Reply-To: References: Message-ID: Hi Andrew, Thanks for the PR. Obviously we're relying 100% of you/RedHat to test these changes as we don't have any AArch64 hardware in our gates. We will review the PR over the next few days. Unfortunately, the Travis based gating we do for github PRs is currently broken pending Travis updating the OpenJDK package to 8u121[1] -Doug [1] https://github.com/travis-ci/travis-ci/issues/7337 > On 3 Apr 2017, at 13:37, Andrew Dinn wrote: > > The following pull request includes changes to improve address lowering > for AArch64. > > https://github.com/graalvm/graal-core/pull/266 > > I would be grateful for review and feedback and, if acceptbale, a pull > to the main repo. > > Purpose > ------- > The point of this change is to allow AArch64 addresses to be converted > to use either index or displacement mode (n.b. index and displacement > cannot be combined on AArch64). This requires a different approach to > AMD64/SPARC because the suitability of a displacement for embedding in a > load/store instruction depends on the nature of that usage > (specifically, the transfer size for the datum affects the decision as > to whether a given displacement can be embedded). > > A secondary part of the change is to implement address improvement > during lowering to allow certain patterns of address combination to be > simplified. > > Implementation > -------------- > The basic change is to provide a new phase AddressLoweringByUsePhase > which schedules addresses to an address lowering implementation per use, > providing it with the ability to take the use into account when doing > the lowering. > > AArch64 provides a callback class AArch64AddressLoweringByUse which > implements this phase. This replaces the previous lowering callback > AArch64AddressLowering which has been deleted. It includes optimization > of certain nested address combinations as per the other address lowering > implementations (there are less such opportunities for AArch64). > > Making use of the new phase also requires modifying the > HotSpotSuiteProvider classes which previously configured the > AddressLoweringPhase used by AMD64, SPARC and AArch64. > > A superclass HotSpotSuiteProviderBase has been factored out of the > original class HotSpotSuiteProvider making it a subclass specific to > AMD64 and SPARC. An alternative subclass, AArch64HotSpotSuiteProvider, > has been provided for AArch64. The two subclasses perform almost all > their work by delegating to the super class. They only differ in how > they configure address lowering. The step which previously added an > AddressLoweringPhase to the low tier is now performed in each subclass. > HotSpotSuiteProvider configures an AddressLoweringPhase while > AArch64HotSpotSuiteProvider configures an AddressLoweringByUsePhase. > > Testing > ------- > > I have run several small Java programs. I have eyeballed the generated > code for these programs and for JDK runtime methods to verify that > address lowering is being done correctly. > > 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 Apr 3 13:03:09 2017 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 3 Apr 2017 14:03:09 +0100 Subject: RFR: Implement better address lowering for AArch64 In-Reply-To: References:

Message-ID: Hi Doug, Thanks for your feedback. On 03/04/17 13:30, Doug Simon wrote: > Thanks for the PR. Obviously we're relying 100% of you/RedHat to test > these changes as we don't have any AArch64 hardware in our gates. We > will review the PR over the next few days. Sure, no problem. I am assuming that Andrew Haley is going to be one of those who review these changes. > Unfortunately, the Travis based gating we do for github PRs is > currently broken pending Travis updating the OpenJDK package to > 8u121[1] I have no idea what (or who? :-) Travis is but I'll be happy to create a new PR rebased to a later master if that becomes necessary. 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 doug.simon at oracle.com Mon Apr 3 13:09:09 2017 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 3 Apr 2017 15:09:09 +0200 Subject: RFR: Implement better address lowering for AArch64 In-Reply-To: References:

Message-ID: <5217F4F1-5998-4550-8509-323CA4BD5E98@oracle.com> > On 3 Apr 2017, at 15:03, Andrew Dinn wrote: > > Hi Doug, > > Thanks for your feedback. > > On 03/04/17 13:30, Doug Simon wrote: >> Thanks for the PR. Obviously we're relying 100% of you/RedHat to test >> these changes as we don't have any AArch64 hardware in our gates. We >> will review the PR over the next few days. > > Sure, no problem. I am assuming that Andrew Haley is going to be one of > those who review these changes. > >> Unfortunately, the Travis based gating we do for github PRs is >> currently broken pending Travis updating the OpenJDK package to >> 8u121[1] > > I have no idea what (or who? :-) Travis is but I'll be happy to create a > new PR rebased to a later master if that becomes necessary. Look for "continuous-integration/travis-ci/pr ? The Travis CI build failed" in th PR and follow the links to learn all about Travis. The configuration for our Travis testing is in the top level .travis.yml file. -Doug From adinn at redhat.com Mon Apr 3 15:37:57 2017 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 3 Apr 2017 16:37:57 +0100 Subject: RFR: Implement better address lowering for AArch64 In-Reply-To: <5217F4F1-5998-4550-8509-323CA4BD5E98@oracle.com> References:

<5217F4F1-5998-4550-8509-323CA4BD5E98@oracle.com> Message-ID: Hi Doug, Hmm, this is getting trickier. I looked at the option of subclassing HotSpotSuitesProvider to define this subclass hierarchy: AMD64HSSP -----\ SPARCHHSSP -----+-- HSSP AArch64HSSP --/ (n.b. HotSpotSuitesProvider and its prospective subclasses names have been abbreviated to HSSP merely so I can fit the class hierarchy on the page -- I really intended the new classes to be AMD64HotSpotSuitesProvider, etc). Unfortunately, I found that there is a name clash with an existing class in the following hierarchy: AMD64HSSP -- AMD64SuitesProvider ----\ SPARCSuitesProvider -----+-- DefaultSuitesProvider AArch64SuitesProvider ---/ I can (sort of) see why the two AMD64 children in this latter hierarchy are distinguished -- each adds a phase to the LIR suites at a slightly different level of generality. However, the names belie the fact that this is happening in the DefaultSuitesProvider hierarchy rather than the HotSpotSuitesProvider hierarchy. I think these subclasses of DefaultSuitesProvider might have been named better as AMD64DefaultSuitesProvider SPARCDefaultSuitesProvider AArch64DefaultSuitesProvider AMD64HotSpotDefaultSuitesProvider or, better still, AMD64DefaultSuitesCreator etc since they are only needed to implement the interface SuitesCreator which is used to type the first argument to the constructor for HotSporSuitesProvider (n.b. use of the Creator names is going to require yet more revision of naming -- the rot set in for this whole hierarchy at the root of the class tree above these classes above DefaultSuitesProvider where its parent, SuitesProviderBase, implements SuitesCreator). Would it be best to rename these 4 classes to include the name Default as above? Or would you recommend some other naming scheme for the subclasses of HotSpotSuitesProvider I need to create? 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 doug.simon at oracle.com Mon Apr 3 16:25:43 2017 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 3 Apr 2017 18:25:43 +0200 Subject: RFR: Implement better address lowering for AArch64 In-Reply-To: References:

<5217F4F1-5998-4550-8509-323CA4BD5E98@oracle.com> Message-ID: <13A08499-8665-4708-B928-706861B1A35F@oracle.com> > > On 3 Apr 2017, at 17:37, Andrew Dinn wrote: > > Hi Doug, > > Hmm, this is getting trickier. > > I looked at the option of subclassing HotSpotSuitesProvider to define > this subclass hierarchy: > > > AMD64HSSP -----\ > SPARCHHSSP -----+-- HSSP > AArch64HSSP --/ > > (n.b. HotSpotSuitesProvider and its prospective subclasses names have > been abbreviated to HSSP merely so I can fit the class hierarchy on > the page -- I really intended the new classes to be > AMD64HotSpotSuitesProvider, etc). > > Unfortunately, I found that there is a name clash with an existing class > in the following hierarchy: > > AMD64HSSP -- AMD64SuitesProvider ----\ > SPARCSuitesProvider -----+-- DefaultSuitesProvider > AArch64SuitesProvider ---/ > > I can (sort of) see why the two AMD64 children in this latter hierarchy > are distinguished -- each adds a phase to the LIR suites at a slightly > different level of generality. However, the names belie the fact that > this is happening in the DefaultSuitesProvider hierarchy rather than the > HotSpotSuitesProvider hierarchy. > > I think these subclasses of DefaultSuitesProvider might have been named > better as > > AMD64DefaultSuitesProvider > SPARCDefaultSuitesProvider > AArch64DefaultSuitesProvider > AMD64HotSpotDefaultSuitesProvider > > or, better still, AMD64DefaultSuitesCreator etc since they are only > needed to implement the interface SuitesCreator which is used to type > the first argument to the constructor for HotSporSuitesProvider (n.b. > use of the Creator names is going to require yet more revision of naming > -- the rot set in for this whole hierarchy at the root of the class tree > above these classes above DefaultSuitesProvider where its parent, > SuitesProviderBase, implements SuitesCreator). > > Would it be best to rename these 4 classes to include the name Default > as above? Or would you recommend some other naming scheme for the > subclasses of HotSpotSuitesProvider I need to create? Hmm, the existing hierarchies are indeed ripe for confusion! I think you're suggestion for AMD64DefaultSuitesCreator etc is the best to clean this up. @Roland: I think you were involved with creation/evolution of the existing code. Does the *DefaultSuitesCreator clean up suggested by Andrew make sense to you? Once we agree on the cleanup, I'm fine with it being done in the same PR. -Doug From roland.schatz at oracle.com Tue Apr 4 08:55:28 2017 From: roland.schatz at oracle.com (Roland Schatz) Date: Tue, 4 Apr 2017 10:55:28 +0200 Subject: Test Interface for Truffle: Good for PE tests? In-Reply-To: <27E450E8-8339-4F39-AF54-56B1DBE6A897@stefan-marr.de> References: <27E450E8-8339-4F39-AF54-56B1DBE6A897@stefan-marr.de> Message-ID: <66902dcf-8c6c-8eba-f953-99c402f7893a@oracle.com> Hi Stefan, On 03/31/2017 01:16 PM, Stefan Marr wrote: > 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? Yes, the idea of that interface is that you can use it to unit-test the partial evaluation and compilation of individual nodes or small AST snippets. You can combine that with CompilerDirectives to explicitly test for constant folding. > > 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 there is a Truffle compiler in the system (i.e. you're running with Graal), then compilation is forced for the final execution of the test AST. This is essentially saving you the need to write a manual warmup loop in the hope of eventually triggering compilation. > > 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]. CompilerDirectives.isCompilationConstant will return true if called from the interpreter, so if you're writing a test that's asserting that something is constant, it should at least not fail if there is no compiler available (but of course it also won't actually test anything). You could also just put a big "if (CompilerDirectives.inCompiledCode())" around the code in the test root node, but that would of course also effectively disable your warmup (which may be totally fine, depending on how you build your test AST). - Roland > > Thanks > Stefan > > [1]: https://github.com/graalvm/truffle/commit/1dce7adb2833abc2aa3f3a4bcd0e0c288a472faf > [2]: https://github.com/graalvm/truffle/issues/47 > From doug.simon at oracle.com Tue Apr 4 09:30:57 2017 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 4 Apr 2017 11:30:57 +0200 Subject: Test Interface for Truffle: Good for PE tests? In-Reply-To: <66902dcf-8c6c-8eba-f953-99c402f7893a@oracle.com> References: <27E450E8-8339-4F39-AF54-56B1DBE6A897@stefan-marr.de> <66902dcf-8c6c-8eba-f953-99c402f7893a@oracle.com> Message-ID: Roland, You may want to consider adding a FAQ section to the javadoc of TruffleRunner to capture some of this. -Doug > On 4 Apr 2017, at 10:55, Roland Schatz wrote: > > Hi Stefan, > > On 03/31/2017 01:16 PM, Stefan Marr wrote: >> 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? > Yes, the idea of that interface is that you can use it to unit-test the partial evaluation and compilation of individual nodes or small AST snippets. > You can combine that with CompilerDirectives to explicitly test for constant folding. > >> >> 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 there is a Truffle compiler in the system (i.e. you're running with Graal), then compilation is forced for the final execution of the test AST. > This is essentially saving you the need to write a manual warmup loop in the hope of eventually triggering compilation. > >> >> 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]. > CompilerDirectives.isCompilationConstant will return true if called from the interpreter, so if you're writing a test that's asserting that something is constant, it should at least not fail if there is no compiler available (but of course it also won't actually test anything). > You could also just put a big "if (CompilerDirectives.inCompiledCode())" around the code in the test root node, but that would of course also effectively disable your warmup (which may be totally fine, depending on how you build your test AST). > > > - Roland > >> >> Thanks >> Stefan >> >> [1]: https://github.com/graalvm/truffle/commit/1dce7adb2833abc2aa3f3a4bcd0e0c288a472faf >> [2]: https://github.com/graalvm/truffle/issues/47 >> > From jaroslav.tulach at oracle.com Tue Apr 4 10:24:12 2017 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Tue, 04 Apr 2017 12:24:12 +0200 Subject: Test Interface for Truffle: Good for PE tests? In-Reply-To: References: <27E450E8-8339-4F39-AF54-56B1DBE6A897@stefan-marr.de> <66902dcf-8c6c-8eba-f953-99c402f7893a@oracle.com> Message-ID: <2810244.uX7F0lmYVg@pracovni> On ?ter? 4. dubna 2017 11:30:57 CEST Doug Simon wrote: > Roland, > > You may want to consider adding a FAQ section to the javadoc of > TruffleRunner to capture some of this. +1 Or rather add the FAQ to the tutorial: http://graalvm.github.io/truffle/javadoc/com/oracle/truffle/tutorial/newlanguage/ package-summary.html that's where people seek for FAQ like info more likely than in a class javadoc. In any case having FAQ somewhere is better than no FAQ. -jt > > On 4 Apr 2017, at 10:55, Roland Schatz wrote: > > > > Hi Stefan, > > > > On 03/31/2017 01:16 PM, Stefan Marr wrote: > >> 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?> > > Yes, the idea of that interface is that you can use it to unit-test the > > partial evaluation and compilation of individual nodes or small AST > > snippets. You can combine that with CompilerDirectives to explicitly test > > for constant folding.> > >> 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 there is a Truffle compiler in the system (i.e. you're running with > > Graal), then compilation is forced for the final execution of the test > > AST. This is essentially saving you the need to write a manual warmup > > loop in the hope of eventually triggering compilation.> > >> 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].> > > CompilerDirectives.isCompilationConstant will return true if called from > > the interpreter, so if you're writing a test that's asserting that > > something is constant, it should at least not fail if there is no > > compiler available (but of course it also won't actually test anything). > > You could also just put a big "if (CompilerDirectives.inCompiledCode())" > > around the code in the test root node, but that would of course also > > effectively disable your warmup (which may be totally fine, depending on > > how you build your test AST). > > > > > > - Roland > > > >> Thanks > >> Stefan > >> > >> [1]: > >> https://github.com/graalvm/truffle/commit/1dce7adb2833abc2aa3f3a4bcd0e0c > >> 288a472faf [2]: https://github.com/graalvm/truffle/issues/47 From adinn at redhat.com Wed Apr 12 11:13:42 2017 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 12 Apr 2017 12:13:42 +0100 Subject: RFR: two small patches to fix AArch64 Message-ID: I have been testing my fix for address lowering on AArch64 Graal by running netbeans and found several errors which crash the JVM. It seems the AArch64 port of Graal is already bust without my changes when it comes to running a large program like this. I am still investigating some remaining problems but I wanted to propose these two small fixes in the backend code generation for inclusion before I propose my full patch. Since these are tiny changes I am simply posting a git diff. Can someone in the project team apply them and push them to the main repo? Or do I have to provide a git PR? regards, Andrew Dinn ----------- Problem 1) Scaled displacement Address verify rule is incorrect This first problem is innocuous until it gets uncovered by my changes but only because no hand-coded scaled displacement instructions happen to have used a large enough offset. Scaled offsets need to allow up to 12 unsigned bits. --- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< ----- git diff graal/org.graalvm.compiler.asm.aarch64/src/org/graalvm/compiler/asm/aarch64/AArch64Address.java diff --git a/graal/org.graalvm.compiler.asm.aarch64/src/org/graalvm/compiler/asm/aarch64/AArch64Address.java b/graal/org.graalvm.compiler.asm.aarch64/src/org/graalvm/compiler/asm/aarch64/AArch64Address.java index 8a48c42..b86b2c4 100644 --- a/graal/org.graalvm.compiler.asm.aarch64/src/org/graalvm/compiler/asm/aarch64/AArch64Address.java +++ b/graal/org.graalvm.compiler.asm.aarch64/src/org/graalvm/compiler/asm/aarch64/AArch64Address.java @@ -286,7 +286,7 @@ public final class AArch64Address extends AbstractAddress { return immediate & NumUtil.getNbitNumberInt(9); case IMMEDIATE_SCALED: // Unsigned value can be returned as-is. - assert NumUtil.isUnsignedNbit(9, immediate); + assert NumUtil.isUnsignedNbit(12, immediate); return immediate; case PC_LITERAL: // 21-bit signed value, but lower 2 bits are always 0 and are shifted out. --- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< ----- Problem 1) Stack-bang shadow region size is waaay over-size The second patch fixes a problem in the stack-banging code generation. On AArch64 page size is normally 64K. The current code to compute the stack bang offset ends up using an offset of 20 * 64K (25 * 64K in dev builds) which is obviously ludicrous. It causes almost immediate stack overflows on any reasonably large program. The following generic change assumes a 4K shadow page unit then rounds up to the resulting stack bang offset to a multiple of the actual page size. n.b. this change merely updates Graal to relect what happens in the latest jdk9/hotspot generic source (see os::init_before_ergo in hotspot/src/share/vm/runtime/os.cpp). --- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< ----- diff --git a/graal/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotHostBackend.java b/graal/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotHostBackend.java index f58232f..7af446d 100644 --- a/graal/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotHostBackend.java +++ b/graal/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotHostBackend.java @@ -22,9 +22,11 @@ */ package org.graalvm.compiler.hotspot; +import static jdk.vm.ci.code.CodeUtil.K; import static jdk.vm.ci.code.CodeUtil.getCallingConvention; import static jdk.vm.ci.common.InitTimer.timer; +import org.graalvm.compiler.core.common.NumUtil; import org.graalvm.compiler.core.common.spi.ForeignCallDescriptor; import org.graalvm.compiler.hotspot.meta.HotSpotHostForeignCallsProvider; import org.graalvm.compiler.hotspot.meta.HotSpotLoweringProvider; @@ -109,7 +111,7 @@ public abstract class HotSpotHostBackend extends HotSpotBackend { // is greater than a page. int pageSize = config.vmPageSize; - int bangEnd = config.stackShadowPages * pageSize; + int bangEnd = NumUtil.roundUp(config.stackShadowPages * 4 * K, pageSize); // This is how far the previous frame's stack banging extended. int bangEndSafe = bangEnd; --- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< ----- From aph at redhat.com Wed Apr 12 11:21:19 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 12 Apr 2017 12:21:19 +0100 Subject: RFR: two small patches to fix AArch64 In-Reply-To: References: Message-ID: On 12/04/17 12:13, Andrew Dinn wrote: > Since these are tiny changes I am simply posting a git diff. Can someone > in the project team apply them and push them to the main repo? Or do I > have to provide a git PR? It's conventional to do that. I think it gets easier with time. Andrew. From doug.simon at oracle.com Wed Apr 12 12:07:51 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 12 Apr 2017 14:07:51 +0200 Subject: RFR: two small patches to fix AArch64 In-Reply-To: References: Message-ID: <73E0CBAF-92A2-4F76-9C10-D813AC8D8D43@oracle.com> Hi Andrew, > On 12 Apr 2017, at 13:13, Andrew Dinn wrote: > > I have been testing my fix for address lowering on AArch64 Graal by > running netbeans and found several errors which crash the JVM. It seems > the AArch64 port of Graal is already bust without my changes when it > comes to running a large program like this. > > I am still investigating some remaining problems but I wanted to propose > these two small fixes in the backend code generation for inclusion > before I propose my full patch. > > Since these are tiny changes I am simply posting a git diff. Can someone > in the project team apply them and push them to the main repo? Or do I > have to provide a git PR? Please provide a github PR. Since you've already submitted one PR, I hope the process is not too onerous and you are getting familiar with it. Feel free to ask for help! -Doug > > regards, > > > Andrew Dinn > ----------- > > Problem 1) Scaled displacement Address verify rule is incorrect > > This first problem is innocuous until it gets uncovered by my changes > but only because no hand-coded scaled displacement instructions happen > to have used a large enough offset. Scaled offsets need to allow up to > 12 unsigned bits. > > --- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< ----- > git diff > graal/org.graalvm.compiler.asm.aarch64/src/org/graalvm/compiler/asm/aarch64/AArch64Address.java > diff --git > a/graal/org.graalvm.compiler.asm.aarch64/src/org/graalvm/compiler/asm/aarch64/AArch64Address.java > b/graal/org.graalvm.compiler.asm.aarch64/src/org/graalvm/compiler/asm/aarch64/AArch64Address.java > index 8a48c42..b86b2c4 100644 > --- > a/graal/org.graalvm.compiler.asm.aarch64/src/org/graalvm/compiler/asm/aarch64/AArch64Address.java > +++ > b/graal/org.graalvm.compiler.asm.aarch64/src/org/graalvm/compiler/asm/aarch64/AArch64Address.java > @@ -286,7 +286,7 @@ public final class AArch64Address extends > AbstractAddress { > return immediate & NumUtil.getNbitNumberInt(9); > case IMMEDIATE_SCALED: > // Unsigned value can be returned as-is. > - assert NumUtil.isUnsignedNbit(9, immediate); > + assert NumUtil.isUnsignedNbit(12, immediate); > return immediate; > case PC_LITERAL: > // 21-bit signed value, but lower 2 bits are always 0 > and are shifted out. > --- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< ----- > > Problem 1) Stack-bang shadow region size is waaay over-size > > The second patch fixes a problem in the stack-banging code generation. > > On AArch64 page size is normally 64K. The current code to compute the > stack bang offset ends up using an offset of 20 * 64K (25 * 64K in dev > builds) which is obviously ludicrous. It causes almost immediate stack > overflows on any reasonably large program. The following generic change > assumes a 4K shadow page unit then rounds up to the resulting stack bang > offset to a multiple of the actual page size. > > n.b. this change merely updates Graal to relect what happens in the > latest jdk9/hotspot generic source (see os::init_before_ergo in > hotspot/src/share/vm/runtime/os.cpp). > > --- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< ----- > diff --git > a/graal/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotHostBackend.java > b/graal/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotHostBackend.java > index f58232f..7af446d 100644 > --- > a/graal/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotHostBackend.java > +++ > b/graal/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotHostBackend.java > @@ -22,9 +22,11 @@ > */ > package org.graalvm.compiler.hotspot; > > +import static jdk.vm.ci.code.CodeUtil.K; > import static jdk.vm.ci.code.CodeUtil.getCallingConvention; > import static jdk.vm.ci.common.InitTimer.timer; > > +import org.graalvm.compiler.core.common.NumUtil; > import org.graalvm.compiler.core.common.spi.ForeignCallDescriptor; > import org.graalvm.compiler.hotspot.meta.HotSpotHostForeignCallsProvider; > import org.graalvm.compiler.hotspot.meta.HotSpotLoweringProvider; > @@ -109,7 +111,7 @@ public abstract class HotSpotHostBackend extends > HotSpotBackend { > // is greater than a page. > > int pageSize = config.vmPageSize; > - int bangEnd = config.stackShadowPages * pageSize; > + int bangEnd = NumUtil.roundUp(config.stackShadowPages * 4 * > K, pageSize); > > // This is how far the previous frame's stack banging extended. > int bangEndSafe = bangEnd; > --- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< ----- From adinn at redhat.com Wed Apr 12 12:55:10 2017 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 12 Apr 2017 13:55:10 +0100 Subject: RFR: two small patches to fix AArch64 In-Reply-To: <73E0CBAF-92A2-4F76-9C10-D813AC8D8D43@oracle.com> References: <73E0CBAF-92A2-4F76-9C10-D813AC8D8D43@oracle.com> Message-ID: <3c6523e3-2a25-3ab7-1150-5c9e8fa2f3c0@redhat.com> On 12/04/17 13:07, Doug Simon wrote: > Please provide a github PR. Since you've already submitted one PR, I > hope the process is not too onerous and you are getting familiar with > it. Feel free to ask for help! Sure, no problem. PR has been created. 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 Wed Apr 12 13:39:30 2017 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 12 Apr 2017 14:39:30 +0100 Subject: RFR: another small patch to fix AArch64 In-Reply-To: <3c6523e3-2a25-3ab7-1150-5c9e8fa2f3c0@redhat.com> References: <73E0CBAF-92A2-4F76-9C10-D813AC8D8D43@oracle.com> <3c6523e3-2a25-3ab7-1150-5c9e8fa2f3c0@redhat.com> Message-ID: <0b3c2a26-864c-fb09-6564-f8e8814f5d6e@redhat.com> Hi Doug, I just opened another PR for a problem with Compress/UncompressPointer on AArch64. regards ----------- 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 12/04/17 13:55, Andrew Dinn wrote: > On 12/04/17 13:07, Doug Simon wrote: >> Please provide a github PR. Since you've already submitted one PR, I >> hope the process is not too onerous and you are getting familiar with >> it. Feel free to ask for help! > > Sure, no problem. PR has been created. > > 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 doug.simon at oracle.com Thu Apr 27 18:26:53 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 27 Apr 2017 20:26:53 +0200 Subject: graal-core and truffle have been merged into new repo Message-ID: <70932730-FF6A-4B7F-9310-3ACA264860E0@oracle.com> To simplify working with Graal, we have consolidated https://github.com/graalvm/graal-core and https://github.com/graalvm/truffle into https://github.com/graalvm/graal. We will be updating the documentation in this new repo in the next few days. In the mean time, new issues and PRs should only be made on https://github.com/graalvm/graal. -Doug