From doug.simon at oracle.com  Mon Aug 13 12:23:12 2018
From: doug.simon at oracle.com (Doug Simon)
Date: Mon, 13 Aug 2018 14:23:12 +0200
Subject: JDK8 no longer required to develop Graal
Message-ID: <71F29949-83AA-4E6A-8409-7B14AEF62057@oracle.com>

Developing Graal has always required a JDK8 to be present in either JAVA_HOME or EXTRA_JAVA_HOMES. Please see http://mail.openjdk.java.net/pipermail/graal-dev/2018-June/005413.html for background on this.

I've recently pushed changes to mx[1] and Graal[2] that removes this requirement. That is, you should now be able to develop Graal with only a JDK11 in JAVA_HOME. I have updated https://github.com/oracle/graal/blob/master/compiler/README.md#building-graal to reflect this.

If you run into any problems developing Graal with only a JDK 11, please open an issue at https://github.com/oracle/graal/issues or send a message to graal-dev at openjdk.java.net.

-Doug

[1] https://github.com/graalvm/mx/commit/c9f873aa979b2a724e7e213fd1e0d4ce7131b87f
[2] https://github.com/oracle/graal/commit/a4070ec3d1b16d49f42694b3f0a46a39010b445c

From adinn at redhat.com  Mon Aug 13 13:44:16 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 13 Aug 2018 14:44:16 +0100
Subject: JDK8 no longer required to develop Graal
In-Reply-To: <71F29949-83AA-4E6A-8409-7B14AEF62057@oracle.com>
References: <71F29949-83AA-4E6A-8409-7B14AEF62057@oracle.com>
Message-ID: <e7de8eda-93c7-2769-ee6a-3672e86440c2@redhat.com>

Hurrah!

Thanks Doug. I'll let you know if I run into any problems.

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 java at stefan-marr.de  Mon Aug 13 13:59:21 2018
From: java at stefan-marr.de (Stefan Marr)
Date: Mon, 13 Aug 2018 14:59:21 +0100
Subject: JDK8 no longer required to develop Graal
In-Reply-To: <71F29949-83AA-4E6A-8409-7B14AEF62057@oracle.com>
References: <71F29949-83AA-4E6A-8409-7B14AEF62057@oracle.com>
Message-ID: <3BAEC877-5295-4F20-9A7D-6ADE443B2C44@stefan-marr.de>

Hi Doug,
Hi Christian:

If I am not mistaken, Truffle also still wants a JDK 8.
Is this requirement going to be lifted, too?

Thanks
Stefan

> On 13 Aug 2018, at 13:23, Doug Simon <doug.simon at oracle.com> wrote:
> 
> Developing Graal has always required a JDK8 to be present in either JAVA_HOME or EXTRA_JAVA_HOMES. Please see http://mail.openjdk.java.net/pipermail/graal-dev/2018-June/005413.html for background on this.
> 
> I've recently pushed changes to mx[1] and Graal[2] that removes this requirement. That is, you should now be able to develop Graal with only a JDK11 in JAVA_HOME. I have updated https://github.com/oracle/graal/blob/master/compiler/README.md#building-graal to reflect this.
> 
> If you run into any problems developing Graal with only a JDK 11, please open an issue at https://github.com/oracle/graal/issues or send a message to graal-dev at openjdk.java.net.
> 
> -Doug
> 
> [1] https://github.com/graalvm/mx/commit/c9f873aa979b2a724e7e213fd1e0d4ce7131b87f
> [2] https://github.com/oracle/graal/commit/a4070ec3d1b16d49f42694b3f0a46a39010b445c

-- 
Stefan Marr
School of Computing, University of Kent
http://stefan-marr.de/research/



From doug.simon at oracle.com  Mon Aug 13 14:12:09 2018
From: doug.simon at oracle.com (Doug Simon)
Date: Mon, 13 Aug 2018 16:12:09 +0200
Subject: JDK8 no longer required to develop Graal
In-Reply-To: <3BAEC877-5295-4F20-9A7D-6ADE443B2C44@stefan-marr.de>
References: <71F29949-83AA-4E6A-8409-7B14AEF62057@oracle.com>
 <3BAEC877-5295-4F20-9A7D-6ADE443B2C44@stefan-marr.de>
Message-ID: <6B963031-BDFD-4806-8D8F-62D0EF861F67@oracle.com>



> On 13 Aug 2018, at 15:59, Stefan Marr <java at stefan-marr.de> wrote:
> 
> Hi Doug,
> Hi Christian:
> 
> If I am not mistaken, Truffle also still wants a JDK 8.
> Is this requirement going to be lifted, too?

It should have been lifted as part of this change. Try `mx --java-home /path/to/jdk-11 gate` to confirm.

-Doug

> 
>> On 13 Aug 2018, at 13:23, Doug Simon <doug.simon at oracle.com> wrote:
>> 
>> Developing Graal has always required a JDK8 to be present in either JAVA_HOME or EXTRA_JAVA_HOMES. Please see http://mail.openjdk.java.net/pipermail/graal-dev/2018-June/005413.html for background on this.
>> 
>> I've recently pushed changes to mx[1] and Graal[2] that removes this requirement. That is, you should now be able to develop Graal with only a JDK11 in JAVA_HOME. I have updated https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_oracle_graal_blob_master_compiler_README.md-23building-2Dgraal&d=DwIFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=2diesXR4Jx9690v_KHWWBRFfK0TM3xLphvbeLhHLIdE&s=l2feHpKTQJ3KQn7Em2MJkA2IR-Wjx5WF6p3a0smcR34&e= to reflect this.
>> 
>> If you run into any problems developing Graal with only a JDK 11, please open an issue at https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_oracle_graal_issues&d=DwIFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=2diesXR4Jx9690v_KHWWBRFfK0TM3xLphvbeLhHLIdE&s=mfqB-VgzV4ejlIy4cAvs_SJYru73RofbGFJfhZytbqQ&e= or send a message to graal-dev at openjdk.java.net.
>> 
>> -Doug
>> 
>> [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_graalvm_mx_commit_c9f873aa979b2a724e7e213fd1e0d4ce7131b87f&d=DwIFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=2diesXR4Jx9690v_KHWWBRFfK0TM3xLphvbeLhHLIdE&s=9s2nl428q5C6p31YcRRcBZWPC4r31wwQn7-TznODd0k&e=
>> [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_oracle_graal_commit_a4070ec3d1b16d49f42694b3f0a46a39010b445c&d=DwIFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=2diesXR4Jx9690v_KHWWBRFfK0TM3xLphvbeLhHLIdE&s=wdXGxW80gruac09E2_QHXi3qrrITLkUlcCitnrbfsg4&e=
> 
> -- 
> Stefan Marr
> School of Computing, University of Kent
> https://urldefense.proofpoint.com/v2/url?u=http-3A__stefan-2Dmarr.de_research_&d=DwIFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=2diesXR4Jx9690v_KHWWBRFfK0TM3xLphvbeLhHLIdE&s=AAJT4JbmS3L8nQ5Ra3UC2MZuYnhOLk74Ux74J86T73U&e=
> 
> 


From thomas.wuerthinger at oracle.com  Wed Aug 15 10:15:22 2018
From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger)
Date: Wed, 15 Aug 2018 12:15:22 +0200
Subject: VMM Call for Participation 
Message-ID: <2467AE55-0E39-497B-B983-482C457E7867@oracle.com>

Hi,

Please consider submitting a talk proposal to the VMM?2018 in Linz (Austria) if you are doing an interesting project using GraalVM or perform research in the area. We are looking forward to discuss the latest ongoing work and results. There will be many members of the GraalVM team at the meet up available for informal discussions.

Details at: https://vmmeetup.github.io/2018/

- thomas

From jackson at jcdav.is  Wed Aug 15 16:07:00 2018
From: jackson at jcdav.is (Jackson Davis)
Date: Wed, 15 Aug 2018 09:07:00 -0700
Subject: JDK8 no longer required to develop Graal
In-Reply-To: <71F29949-83AA-4E6A-8409-7B14AEF62057@oracle.com>
References: <71F29949-83AA-4E6A-8409-7B14AEF62057@oracle.com>
Message-ID: <CAHeMEgLyghPcw-=c1Jw3vhgh6Qm4TVbQfG5o9EiTkG7FAcXy+g@mail.gmail.com>

First off, a belated thanks for this - I've been wanting to get back into
playing around with Graal, and this makes things much easier.

As a related note though, the story for using the graph visualization tools
is currently a bit of a mess. In particular, c1vis seems to be based off an
earlier version of Netbeans that doesn't work with JDKs >= 9, I see an
error message similar to this in the log:
https://stackoverflow.com/questions/46170762/netbeans-8-1-ide-exits-unexpectedly-on-ubuntu-17-04

But then if I supply a normal (non-JVMCI) jdk8 build as a java home to use,
mx rejects it (even with JVMCI_VERSION_CHECK=ignore), even though JVMCI
shouldn't be necessary for just running this. The workaround seems to be
just manually downloading c1vis and running it pointing at a jdk8, but it
would be nice to be able to do this through the mx command.

IGV doesn't seem to have this issue, but since the most easily-accessible
javafx-compatible builds are jdk8-based (eg sudo apt-get install openjfx),
you still need to jump through some hoops of having the right jdk to get it
to work. Ideally the JVMCI requirement could be avoided for these?

-Jackson


On Mon, Aug 13, 2018 at 5:23 AM, Doug Simon <doug.simon at oracle.com> wrote:

> Developing Graal has always required a JDK8 to be present in either
> JAVA_HOME or EXTRA_JAVA_HOMES. Please see http://mail.openjdk.java.net/
> pipermail/graal-dev/2018-June/005413.html for background on this.
>
> I've recently pushed changes to mx[1] and Graal[2] that removes this
> requirement. That is, you should now be able to develop Graal with only a
> JDK11 in JAVA_HOME. I have updated https://github.com/oracle/
> graal/blob/master/compiler/README.md#building-graal to reflect this.
>
> If you run into any problems developing Graal with only a JDK 11, please
> open an issue at https://github.com/oracle/graal/issues or send a message
> to graal-dev at openjdk.java.net.
>
> -Doug
>
> [1] https://github.com/graalvm/mx/commit/c9f873aa979b2a724e7e213fd1e0d4
> ce7131b87f
> [2] https://github.com/oracle/graal/commit/a4070ec3d1b16d49f42694b3f0a46a
> 39010b445c

From doug.simon at oracle.com  Wed Aug 15 16:19:32 2018
From: doug.simon at oracle.com (Doug Simon)
Date: Wed, 15 Aug 2018 18:19:32 +0200
Subject: JDK8 no longer required to develop Graal
In-Reply-To: <CAHeMEgLyghPcw-=c1Jw3vhgh6Qm4TVbQfG5o9EiTkG7FAcXy+g@mail.gmail.com>
References: <71F29949-83AA-4E6A-8409-7B14AEF62057@oracle.com>
 <CAHeMEgLyghPcw-=c1Jw3vhgh6Qm4TVbQfG5o9EiTkG7FAcXy+g@mail.gmail.com>
Message-ID: <DE6A6096-7DCD-42B3-8B28-701A9F0096AC@oracle.com>



> On 15 Aug 2018, at 18:07, Jackson Davis <jackson at jcdav.is> wrote:
> 
> First off, a belated thanks for this - I've been wanting to get back into playing around with Graal, and this makes things much easier.

Good to hear - that was the point ;-)

> As a related note though, the story for using the graph visualization tools is currently a bit of a mess. In particular, c1vis seems to be based off an earlier version of Netbeans that doesn't work with JDKs >= 9, I see an error message similar to this in the log: https://stackoverflow.com/questions/46170762/netbeans-8-1-ide-exits-unexpectedly-on-ubuntu-17-04

@Christian, Svata: Do you know what is necessary to update C1Visualizer to a more recent NetBeans platform that supports JDK 9+?

> 
> But then if I supply a normal (non-JVMCI) jdk8 build as a java home to use, mx rejects it (even with JVMCI_VERSION_CHECK=ignore), even though JVMCI shouldn't be necessary for just running this. The workaround seems to be just manually downloading c1vis and running it pointing at a jdk8, but it would be nice to be able to do this through the mx command.

I think the best path forward is producing a new C1Visualizer as mentioned above.

> IGV doesn't seem to have this issue, but since the most easily-accessible javafx-compatible builds are jdk8-based (eg sudo apt-get install openjfx), you still need to jump through some hoops of having the right jdk to get it to work. Ideally the JVMCI requirement could be avoided for these?

We will look into it.

-Doug

> 
> On Mon, Aug 13, 2018 at 5:23 AM, Doug Simon <doug.simon at oracle.com> wrote:
> Developing Graal has always required a JDK8 to be present in either JAVA_HOME or EXTRA_JAVA_HOMES. Please see http://mail.openjdk.java.net/pipermail/graal-dev/2018-June/005413.html for background on this.
> 
> I've recently pushed changes to mx[1] and Graal[2] that removes this requirement. That is, you should now be able to develop Graal with only a JDK11 in JAVA_HOME. I have updated https://github.com/oracle/graal/blob/master/compiler/README.md#building-graal to reflect this.
> 
> If you run into any problems developing Graal with only a JDK 11, please open an issue at https://github.com/oracle/graal/issues or send a message to graal-dev at openjdk.java.net.
> 
> -Doug
> 
> [1] https://github.com/graalvm/mx/commit/c9f873aa979b2a724e7e213fd1e0d4ce7131b87f
> [2] https://github.com/oracle/graal/commit/a4070ec3d1b16d49f42694b3f0a46a39010b445c
> 


From jean-philippe.halimi at intel.com  Wed Aug 15 18:57:06 2018
From: jean-philippe.halimi at intel.com (Halimi, Jean-Philippe)
Date: Wed, 15 Aug 2018 18:57:06 +0000
Subject: Graal compiler: AMD64 Intrinsics design
Message-ID: <E55B315EE3E2AA479F9915DAEECA2423451BB1F2@ORSMSX116.amr.corp.intel.com>

Hello everyone,

I'm getting started with the Graal source code and I'd like to add support for new BMI intrinsics, along with these already in place. I'm looking for help from people who developed the existing intrinsics infrastructure. Namely, I would like to double check that my initial understanding is correct.

Could you please let me know if the following steps are correct and sufficient?

1. org.graalvm.compiler.asm.amd64/src/org/graalvm/compiler/asm/amd64/ --> will need to add any new type of instructions there if necessary
2. org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/ --> will need to add new LIR types if necessary, typically in a new Node class that will represent the intrinsic. Design in pseudo code would be as follows:

public final class AMD64NewNode extends UnaryNode implements ArithmeticLirLowerable {
   a. Constructor
   b. tryFold(ValueNode value) method: will try convert the input value to the corresponding value if possible.
   c. generate method: will generate the appropriate LIR containing the intrinsic in the builder.
}

3. Add an entry in org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/AMD64GraphBuilderPlugins.java in order to support the intrinsic in the graph builder if hardware is supported

Thank you,

Jp

From Zhongwei.Yao at arm.com  Thu Aug 16 02:24:44 2018
From: Zhongwei.Yao at arm.com (Zhongwei Yao)
Date: Thu, 16 Aug 2018 02:24:44 +0000
Subject: JDK8 no longer required to develop Graal
In-Reply-To: <71F29949-83AA-4E6A-8409-7B14AEF62057@oracle.com>
References: <71F29949-83AA-4E6A-8409-7B14AEF62057@oracle.com>
Message-ID: <AM4PR0801MB1473345BC2861017A47FD1DE9D3E0@AM4PR0801MB1473.eurprd08.prod.outlook.com>

Hi, Doug,

Thanks for doing this! I verified it on AArch64 and it works without JDK8 now. It makes the development process for AArch64 platform much easier!

And I notice there are 2 categories of the test in Travis CI for Graal. One uses JDK8 and another uses JDK11. Since JDK8 is no longer required to develop Graal, but I see the FindBugs task in CI test (e.g. https://travis-ci.org/oracle/graal/jobs/416506388) depends on JDK8. Is this the only reason to keep JDK8 in the CI test? Or is there any other reasons?

--
Best regards,
Zhongwei

________________________________________
From: graal-dev <graal-dev-bounces at openjdk.java.net> on behalf of Doug Simon <doug.simon at oracle.com>
Sent: Monday, August 13, 2018 8:23 PM
To: graal developers; hotspot compiler
Subject: JDK8 no longer required to develop Graal

Developing Graal has always required a JDK8 to be present in either JAVA_HOME or EXTRA_JAVA_HOMES. Please see http://mail.openjdk.java.net/pipermail/graal-dev/2018-June/005413.html for background on this.

I've recently pushed changes to mx[1] and Graal[2] that removes this requirement. That is, you should now be able to develop Graal with only a JDK11 in JAVA_HOME. I have updated https://github.com/oracle/graal/blob/master/compiler/README.md#building-graal to reflect this.

If you run into any problems developing Graal with only a JDK 11, please open an issue at https://github.com/oracle/graal/issues or send a message to graal-dev at openjdk.java.net.

-Doug

[1] https://github.com/graalvm/mx/commit/c9f873aa979b2a724e7e213fd1e0d4ce7131b87f
[2] https://github.com/oracle/graal/commit/a4070ec3d1b16d49f42694b3f0a46a39010b445c

From doug.simon at oracle.com  Thu Aug 16 07:32:31 2018
From: doug.simon at oracle.com (Doug Simon)
Date: Thu, 16 Aug 2018 09:32:31 +0200
Subject: JDK8 no longer required to develop Graal
In-Reply-To: <AM4PR0801MB1473345BC2861017A47FD1DE9D3E0@AM4PR0801MB1473.eurprd08.prod.outlook.com>
References: <71F29949-83AA-4E6A-8409-7B14AEF62057@oracle.com>
 <AM4PR0801MB1473345BC2861017A47FD1DE9D3E0@AM4PR0801MB1473.eurprd08.prod.outlook.com>
Message-ID: <BD1A8EAC-0B4B-416F-B0E7-FF09BD4301F9@oracle.com>

Hi Zhongwei,

> On 16 Aug 2018, at 04:24, Zhongwei Yao <Zhongwei.Yao at arm.com> wrote:
> 
> Hi, Doug,
> 
> Thanks for doing this! I verified it on AArch64 and it works without JDK8 now. It makes the development process for AArch64 platform much easier!

Great to hear.

> And I notice there are 2 categories of the test in Travis CI for Graal. One uses JDK8 and another uses JDK11. Since JDK8 is no longer required to develop Graal, but I see the FindBugs task in CI test (e.g. https://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.org_oracle_graal_jobs_416506388&d=DwIFAw&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=k4L2yedU7ckDo1xGcB0K3hhs7EV8gOS_8peuXBCO91k&s=AdusKENwNvXh-uiOjQII-gLtchnsz-ef80rAk_RDdk4&e=) depends on JDK8. Is this the only reason to keep JDK8 in the CI test? Or is there any other reasons?

We need to continue to test against JDK8 as long as it is a supported Graal platform (which will be for quite a while).

-Doug

> 
> --
> Best regards,
> Zhongwei
> 
> ________________________________________
> From: graal-dev <graal-dev-bounces at openjdk.java.net> on behalf of Doug Simon <doug.simon at oracle.com>
> Sent: Monday, August 13, 2018 8:23 PM
> To: graal developers; hotspot compiler
> Subject: JDK8 no longer required to develop Graal
> 
> Developing Graal has always required a JDK8 to be present in either JAVA_HOME or EXTRA_JAVA_HOMES. Please see http://mail.openjdk.java.net/pipermail/graal-dev/2018-June/005413.html for background on this.
> 
> I've recently pushed changes to mx[1] and Graal[2] that removes this requirement. That is, you should now be able to develop Graal with only a JDK11 in JAVA_HOME. I have updated https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_oracle_graal_blob_master_compiler_README.md-23building-2Dgraal&d=DwIFAw&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=k4L2yedU7ckDo1xGcB0K3hhs7EV8gOS_8peuXBCO91k&s=-WrO2i03oatnQaALPLdUIlPrPsK4WDDFTuU_u5ZTUK0&e= to reflect this.
> 
> If you run into any problems developing Graal with only a JDK 11, please open an issue at https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_oracle_graal_issues&d=DwIFAw&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=k4L2yedU7ckDo1xGcB0K3hhs7EV8gOS_8peuXBCO91k&s=42IhS-_h_JlBWsr5NTGXkldJCZJTTHTAvIpGEEPoPKE&e= or send a message to graal-dev at openjdk.java.net.
> 
> -Doug
> 
> [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_graalvm_mx_commit_c9f873aa979b2a724e7e213fd1e0d4ce7131b87f&d=DwIFAw&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=k4L2yedU7ckDo1xGcB0K3hhs7EV8gOS_8peuXBCO91k&s=5uI0IS5qfbh3bprvKrKNJrYEt_OmFgYhel-aUtW77nU&e=
> [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_oracle_graal_commit_a4070ec3d1b16d49f42694b3f0a46a39010b445c&d=DwIFAw&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=k4L2yedU7ckDo1xGcB0K3hhs7EV8gOS_8peuXBCO91k&s=fB5bRWslOpRdOjhcRI7OkOvmf_S_LV5dw22Lr_ddY8I&e=


From doug.simon at oracle.com  Thu Aug 16 10:21:02 2018
From: doug.simon at oracle.com (Doug Simon)
Date: Thu, 16 Aug 2018 12:21:02 +0200
Subject: Graal compiler: AMD64 Intrinsics design
In-Reply-To: <E55B315EE3E2AA479F9915DAEECA2423451BB1F2@ORSMSX116.amr.corp.intel.com>
References: <E55B315EE3E2AA479F9915DAEECA2423451BB1F2@ORSMSX116.amr.corp.intel.com>
Message-ID: <D6D068AF-CC1F-4EEE-AF49-D77B28AD0C61@oracle.com>

Hi Jp,

> On 15 Aug 2018, at 20:57, Halimi, Jean-Philippe <jean-philippe.halimi at intel.com> wrote:
> 
> Hello everyone,
> 
> I'm getting started with the Graal source code and I'd like to add support for new BMI intrinsics, along with these already in place. I'm looking for help from people who developed the existing intrinsics infrastructure. Namely, I would like to double check that my initial understanding is correct.
> 
> Could you please let me know if the following steps are correct and sufficient?
> 
> 1. org.graalvm.compiler.asm.amd64/src/org/graalvm/compiler/asm/amd64/ --> will need to add any new type of instructions there if necessary

Yes.

> 2. org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/ --> will need to add new LIR types if necessary, typically in a new Node class that will represent the intrinsic. Design in pseudo code would be as follows:
> 
> public final class AMD64NewNode extends UnaryNode implements ArithmeticLirLowerable {
>   a. Constructor
>   b. tryFold(ValueNode value) method: will try convert the input value to the corresponding value if possible.
>   c. generate method: will generate the appropriate LIR containing the intrinsic in the builder.
> }

Yes. Also look at org.graalvm.compiler.replacements.amd64.AMD64CountTrailingZerosNode for inspiration.
> 
> 3. Add an entry in org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/AMD64GraphBuilderPlugins.java in order to support the intrinsic in the graph builder if hardware is supported

Correct.

Seems like you're heading in the right direction. As soon as you have a PR at https://github.com/oracle/graal/pulls, it will be easier offer more detailed input.

-Doug

From gilles.m.duboscq at oracle.com  Thu Aug 16 10:33:13 2018
From: gilles.m.duboscq at oracle.com (Gilles Duboscq)
Date: Thu, 16 Aug 2018 12:33:13 +0200
Subject: Graal compiler: AMD64 Intrinsics design
In-Reply-To: <E55B315EE3E2AA479F9915DAEECA2423451BB1F2@ORSMSX116.amr.corp.intel.com>
References: <E55B315EE3E2AA479F9915DAEECA2423451BB1F2@ORSMSX116.amr.corp.intel.com>
Message-ID: <caddfdbc-1452-9b11-1e11-141993be24a1@oracle.com>

Hi Jean-Philippe,

Thanks for reaching out.

I think in general your steps are right.

A few things though about the particular use case:
- If i remember correctly, a lot of (all?) the BMI instructions use a VEX encoding. Currently our assembler makes some assumption about VEX-encoded instructions using some (x|y|z)mm registers.
  Some refactoring will be needed to clean that up and allow VEX-encoded instructions that only operate on general purpose registers.

- Which instructions do you want to implement an instrinsic for?
  It seems to me like most of them can either be matched in the back-end without having to add high-level nodes or intrinsics (see AMD64NodeMatchRules) or emitted when available:
  - In BMI1 we already use TZCNT and the rest can be matched,
  - In BMI2 (ROR|SAR|SHR|SHL|MUL)X can be emitted instead of the normal version when available.
  - BZHI can also probably be matched from something like `x & ~((1 << p) - 1)`?
  - PDEP & PEXT look like good candidates for intrinsics but which method are would they be intrinsics for?
  Maybe you are rather looking to create an intrinsic for an other high-level method?

Best regards,
 Gilles

On 15/08/18 20:57, Halimi, Jean-Philippe wrote:
> Hello everyone,
> 
> I'm getting started with the Graal source code and I'd like to add support for new BMI intrinsics, along with these already in place. I'm looking for help from people who developed the existing intrinsics infrastructure. Namely, I would like to double check that my initial understanding is correct.
> 
> Could you please let me know if the following steps are correct and sufficient?
> 
> 1. org.graalvm.compiler.asm.amd64/src/org/graalvm/compiler/asm/amd64/ --> will need to add any new type of instructions there if necessary
> 2. org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/ --> will need to add new LIR types if necessary, typically in a new Node class that will represent the intrinsic. Design in pseudo code would be as follows:
> 
> public final class AMD64NewNode extends UnaryNode implements ArithmeticLirLowerable {
>    a. Constructor
>    b. tryFold(ValueNode value) method: will try convert the input value to the corresponding value if possible.
>    c. generate method: will generate the appropriate LIR containing the intrinsic in the builder.
> }
> 
> 3. Add an entry in org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/AMD64GraphBuilderPlugins.java in order to support the intrinsic in the graph builder if hardware is supported
> 
> Thank you,
> 
> Jp
> 

From doug.simon at oracle.com  Fri Aug 17 08:14:57 2018
From: doug.simon at oracle.com (Doug Simon)
Date: Fri, 17 Aug 2018 10:14:57 +0200
Subject: JVMCI 0.47 released
Message-ID: <FE799A52-EAB6-4CF3-8AB4-16FB16CB3564@oracle.com>

JVMCI 0.47 contains the following changes:

[GR-11253] Do not swallow errors when converting methods and fields to reflection objects (JDK-8209535).
[GR-11104] Invalidate nmethods instead of directly unloading them when the InstalledCode is dropped.
[GR-11037] Make sure volatile fields are read as volatile (JDK-8209625).
[GR-7928] Build Labs JDK for Windows.
[GR-10928] Backport JDK 11 JVMCI lazy class initialization changes.
[GR-10955] Guard calls to continuation_offset (JDK-8209626).
[GR-10901] Updated dependency locations.
[GR-10854] Made installation of hsdis configurable.
[GR-10846] Avoid unnecessary class resolution in Reflection::check_for_inner_class (JDK-8079784).
[GR-10759] C1 does backedge profiling incorrectly.
[GR-10769] Fix code that triggers newer gcc warnings.
[GR-10714] Update sigtest definitions.

The OracleJDK based binaries will soon be available at:

http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html

The openjdk Linux and macOS binaries are at:

https://github.com/graalvm/openjdk8-jvmci-builder/releases/tag/jvmci-0.47

-Doug


From jean-philippe.halimi at intel.com  Mon Aug 20 08:52:36 2018
From: jean-philippe.halimi at intel.com (Halimi, Jean-Philippe)
Date: Mon, 20 Aug 2018 08:52:36 +0000
Subject: Graal for Windows?
Message-ID: <E55B315EE3E2AA479F9915DAEECA2423451BBC5A@ORSMSX116.amr.corp.intel.com>

Dear all,

I've successfully been able to build and run the Graal compiler for Linux, but I was hoping to have my IDE setup on Windows, so I tried to get a Windows build. There's a short mention of it in the wiki (here: https://github.com/oracle/graal/blob/master/compiler/README.md, mention of using mx.cmd instead of mx) but the steps are bash-specific and unclear.

That brings me to a few questions:
- Is Windows supported for Graal development as of now?
- Am I expected to use Cygwin (bash) to build it?
- Is there a tutorial available?

Thanks for your help,

Jp 

From doug.simon at oracle.com  Mon Aug 20 09:45:56 2018
From: doug.simon at oracle.com (Doug Simon)
Date: Mon, 20 Aug 2018 11:45:56 +0200
Subject: Graal for Windows?
In-Reply-To: <E55B315EE3E2AA479F9915DAEECA2423451BBC5A@ORSMSX116.amr.corp.intel.com>
References: <E55B315EE3E2AA479F9915DAEECA2423451BBC5A@ORSMSX116.amr.corp.intel.com>
Message-ID: <1BA0579A-8FDB-4502-8B14-1788A6D5D4D8@oracle.com>

Hi Halimi,

We are very close to having a Windows machine in our CI system. Once that's up and running and gating Graal commits, we will be able to declare Windows a supported platform for *Graal* development and update the relevant documentation.

Aleksandar Pejovic may be able to provide further detail and more precise timelines.

-Doug

> On 20 Aug 2018, at 10:52, Halimi, Jean-Philippe <jean-philippe.halimi at intel.com> wrote:
> 
> Dear all,
> 
> I've successfully been able to build and run the Graal compiler for Linux, but I was hoping to have my IDE setup on Windows, so I tried to get a Windows build. There's a short mention of it in the wiki (here: https://github.com/oracle/graal/blob/master/compiler/README.md, mention of using mx.cmd instead of mx) but the steps are bash-specific and unclear.
> 
> That brings me to a few questions:
> - Is Windows supported for Graal development as of now?
> - Am I expected to use Cygwin (bash) to build it?
> - Is there a tutorial available?
> 
> Thanks for your help,
> 
> Jp 


From aleksandar.pejovic at oracle.com  Tue Aug 21 00:44:56 2018
From: aleksandar.pejovic at oracle.com (=?utf-8?Q?Aleksandar_Pejovi=C4=87?=)
Date: Tue, 21 Aug 2018 02:44:56 +0200
Subject: Graal for Windows?
In-Reply-To: <1BA0579A-8FDB-4502-8B14-1788A6D5D4D8@oracle.com>
References: <E55B315EE3E2AA479F9915DAEECA2423451BBC5A@ORSMSX116.amr.corp.intel.com>
 <1BA0579A-8FDB-4502-8B14-1788A6D5D4D8@oracle.com>
Message-ID: <201808210044.w7L0ivcp029878@aserv0122.oracle.com>

Hi Halimi,

Assuming you?re asking about Java 8, all that?s needed for building Graal on Windows is:
- JVMCI enabled JDK 8 (as Doug mentioned, we?ll be providing it really soon)
- MSVC 2010 SP1 compiler (for native projects, e.g., Truffle NFI)

Cygwin or other bash-like environments are not necessary, unless you want to build JVMCI enabled JDK 8 yourself.

That said, support for the native projects is still ongoing. Which means that at the moment you can only build non-native projects, e.g., by running `mx build --no-native` from `graal\compiler`.

Once everything is built, you should run `mx ideinit` (or IDE specific version) to set up your IDE. In general, IDE support works well, but there might be some Windows specific issues, simply because it hasn?t been used much on Windows yet.

-Aleksandar


From: Doug Simon
Sent: Monday, August 20, 2018 11:45 AM
To: Halimi, Jean-Philippe
Cc: graal-dev at openjdk.java.net; Aleksandar Pejovi?
Subject: Re: Graal for Windows?

Hi Halimi,

We are very close to having a Windows machine in our CI system. Once that's up and running and gating Graal commits, we will be able to declare Windows a supported platform for *Graal* development and update the relevant documentation.

Aleksandar Pejovic may be able to provide further detail and more precise timelines.

-Doug

> On 20 Aug 2018, at 10:52, Halimi, Jean-Philippe <jean-philippe.halimi at intel.com> wrote:
> 
> Dear all,
> 
> I've successfully been able to build and run the Graal compiler for Linux, but I was hoping to have my IDE setup on Windows, so I tried to get a Windows build. There's a short mention of it in the wiki (here: https://github.com/oracle/graal/blob/master/compiler/README.md, mention of using mx.cmd instead of mx) but the steps are bash-specific and unclear.
> 
> That brings me to a few questions:
> - Is Windows supported for Graal development as of now?
> - Am I expected to use Cygwin (bash) to build it?
> - Is there a tutorial available?
> 
> Thanks for your help,
> 
> Jp 



From doug.simon at oracle.com  Tue Aug 21 09:53:11 2018
From: doug.simon at oracle.com (Doug Simon)
Date: Tue, 21 Aug 2018 11:53:11 +0200
Subject: JVMCI 0.48 released
Message-ID: <7C4DE3DA-5DF3-403E-828D-1C88BEB70DAF@oracle.com>

JVMCI 0.48 contains the following fix:

[GR-11357] Fix too strict No_Safepoint_Verifier (JDK-8209624)

The OracleJDK based binaries will soon be available at:

http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html

The OpenJDK Linux and macOS binaries are at:

https://github.com/graalvm/openjdk8-jvmci-builder/releases/tag/jvmci-0.48

-Doug


From rajangdavis at gmail.com  Wed Aug 22 18:36:17 2018
From: rajangdavis at gmail.com (Rajan Davis)
Date: Wed, 22 Aug 2018 11:36:17 -0700
Subject: Graal for Windows?
In-Reply-To: <201808210044.w7L0ivcp029878@aserv0122.oracle.com>
References: <E55B315EE3E2AA479F9915DAEECA2423451BBC5A@ORSMSX116.amr.corp.intel.com>
 <1BA0579A-8FDB-4502-8B14-1788A6D5D4D8@oracle.com>
 <201808210044.w7L0ivcp029878@aserv0122.oracle.com>
Message-ID: <CAE9KkctnW0W_xdxUWNJx8APWLKWFO5bQKsa480fGfLGxZ-_-qA@mail.gmail.com>

Hi Halimi,

I am also not sure if these steps are 100% up to date with the latest
build, but they were enough to get graal running in the Linux Subsystem on
Windows 10 roughly 4 months ago:

1. Enable and Install Ubuntu for Windows 10:
https://docs.microsoft.com/en-us/windows/wsl/install-win10
2. Download the EE edition of GraalVM to Windows:
http://www.graalvm.org/downloads/
3. Mount the folder that has the tar file:
https://stackoverflow.com/a/42586455/2548452
4. Unzip the files (tar xvfs graalvm-ee-1.0.0-rc1-linux-amd64.tar.gz)
5. Create a .bash_profile for setting the $PATH (my personal preference)
6. Follow the instructions from the following up until the "Running
Programs": http://www.graalvm.org/docs/getting-started/
7. Follow instructions for installing LLVM and locales:
https://github.com/oracle/truffleruby#system-compatibility
8. Follow instructions for installing libssl-dev:
https://github.com/oracle/truffleruby/blob/master/doc/user/i...
9. NOW continue on with everything _after_ "Running Programs":
http://www.graalvm.org/docs/getting-started/

*Getting npm to work:*
I could run node -v, but could not run npm and I was getting this error:

> jvm library could not be loaded:
> /home/raj/graalvm/jre/lib/polyglot/libpolyglot.so: cannot enable executable
> stack as shared object requires: Invalid argument

I fixed it by running the following:

1. sudo apt-get install prelink

2. sudo execstack -c ~/graalvm/jre/lib/polyglot/libpolyglot.so

There were still some issues with npm, but you should be able to get
started working graal.

Hope this helps.

-Raj

On Mon, Aug 20, 2018 at 5:45 PM Aleksandar Pejovi? <
aleksandar.pejovic at oracle.com> wrote:

> Hi Halimi,
>
> Assuming you?re asking about Java 8, all that?s needed for building Graal
> on Windows is:
> - JVMCI enabled JDK 8 (as Doug mentioned, we?ll be providing it really
> soon)
> - MSVC 2010 SP1 compiler (for native projects, e.g., Truffle NFI)
>
> Cygwin or other bash-like environments are not necessary, unless you want
> to build JVMCI enabled JDK 8 yourself.
>
> That said, support for the native projects is still ongoing. Which means
> that at the moment you can only build non-native projects, e.g., by running
> `mx build --no-native` from `graal\compiler`.
>
> Once everything is built, you should run `mx ideinit` (or IDE specific
> version) to set up your IDE. In general, IDE support works well, but there
> might be some Windows specific issues, simply because it hasn?t been used
> much on Windows yet.
>
> -Aleksandar
>
>
> From: Doug Simon
> Sent: Monday, August 20, 2018 11:45 AM
> To: Halimi, Jean-Philippe
> Cc: graal-dev at openjdk.java.net; Aleksandar Pejovi?
> Subject: Re: Graal for Windows?
>
> Hi Halimi,
>
> We are very close to having a Windows machine in our CI system. Once
> that's up and running and gating Graal commits, we will be able to declare
> Windows a supported platform for *Graal* development and update the
> relevant documentation.
>
> Aleksandar Pejovic may be able to provide further detail and more precise
> timelines.
>
> -Doug
>
> > On 20 Aug 2018, at 10:52, Halimi, Jean-Philippe <
> jean-philippe.halimi at intel.com> wrote:
> >
> > Dear all,
> >
> > I've successfully been able to build and run the Graal compiler for
> Linux, but I was hoping to have my IDE setup on Windows, so I tried to get
> a Windows build. There's a short mention of it in the wiki (here:
> https://github.com/oracle/graal/blob/master/compiler/README.md, mention
> of using mx.cmd instead of mx) but the steps are bash-specific and unclear.
> >
> > That brings me to a few questions:
> > - Is Windows supported for Graal development as of now?
> > - Am I expected to use Cygwin (bash) to build it?
> > - Is there a tutorial available?
> >
> > Thanks for your help,
> >
> > Jp
>
>
>

From Zhongwei.Yao at arm.com  Thu Aug 23 01:39:27 2018
From: Zhongwei.Yao at arm.com (Zhongwei Yao)
Date: Thu, 23 Aug 2018 01:39:27 +0000
Subject: Fw: Where to find the 3rd party libraries used by --with-graalunit-lib
In-Reply-To: <HE1PR0801MB148290FDB2DAA1DECD83DD679D310@HE1PR0801MB1482.eurprd08.prod.outlook.com>
References: <HE1PR0801MB148290FDB2DAA1DECD83DD679D310@HE1PR0801MB1482.eurprd08.prod.outlook.com>
Message-ID: <AM4PR0801MB147395B9D4E31E7E1FFA8BF99D370@AM4PR0801MB1473.eurprd08.prod.outlook.com>

Hi, all, could you point out where to find the graalunit-lib path?

--
Best regards,
Zhongwei

________________________________________
From: Zhongwei Yao
Sent: Tuesday, August 21, 2018 6:56 PM
To: build-dev at openjdk.java.net
Cc: nd
Subject: Where to find the 3rd party libraries used by --with-graalunit-lib

Hi, all,

To run Graal unit test included in OpenJDK's jtreg tests, I need to add "-with-graalunit-lib" to specify the graalunit-lib path. But I can't find where I can get such libs. Could you point me to where or how to get them? Thanks!

--
Best regards,
Zhongwei

From ekaterina.pavlova at oracle.com  Thu Aug 23 05:49:56 2018
From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova)
Date: Wed, 22 Aug 2018 22:49:56 -0700
Subject: Fw: Where to find the 3rd party libraries used by
 --with-graalunit-lib
In-Reply-To: <AM4PR0801MB147395B9D4E31E7E1FFA8BF99D370@AM4PR0801MB1473.eurprd08.prod.outlook.com>
References: <HE1PR0801MB148290FDB2DAA1DECD83DD679D310@HE1PR0801MB1482.eurprd08.prod.outlook.com>
 <AM4PR0801MB147395B9D4E31E7E1FFA8BF99D370@AM4PR0801MB1473.eurprd08.prod.outlook.com>
Message-ID: <aaa2e2b9-66fb-22b6-e06b-85c5170795b0@oracle.com>

Hi Zhongwei,

Please see test/hotspot/jtreg/compiler/graalunit/README.md

Regards,
-katya

On 8/22/18 6:39 PM, Zhongwei Yao wrote:
> Hi, all, could you point out where to find the graalunit-lib path?
> 
> --
> Best regards,
> Zhongwei
> 
> ________________________________________
> From: Zhongwei Yao
> Sent: Tuesday, August 21, 2018 6:56 PM
> To: build-dev at openjdk.java.net
> Cc: nd
> Subject: Where to find the 3rd party libraries used by --with-graalunit-lib
> 
> Hi, all,
> 
> To run Graal unit test included in OpenJDK's jtreg tests, I need to add "-with-graalunit-lib" to specify the graalunit-lib path. But I can't find where I can get such libs. Could you point me to where or how to get them? Thanks!
> 
> --
> Best regards,
> Zhongwei
> 


From Zhongwei.Yao at arm.com  Thu Aug 23 07:04:39 2018
From: Zhongwei.Yao at arm.com (Zhongwei Yao)
Date: Thu, 23 Aug 2018 07:04:39 +0000
Subject: Fw: Where to find the 3rd party libraries used by
 --with-graalunit-lib
In-Reply-To: <aaa2e2b9-66fb-22b6-e06b-85c5170795b0@oracle.com>
References: <HE1PR0801MB148290FDB2DAA1DECD83DD679D310@HE1PR0801MB1482.eurprd08.prod.outlook.com>
 <AM4PR0801MB147395B9D4E31E7E1FFA8BF99D370@AM4PR0801MB1473.eurprd08.prod.outlook.com>,
 <aaa2e2b9-66fb-22b6-e06b-85c5170795b0@oracle.com>
Message-ID: <AM4PR0801MB1473C28495D84762E058F7A29D370@AM4PR0801MB1473.eurprd08.prod.outlook.com>

Ekaterina, Thanks!

--
Best regards,
Zhongwei

________________________________________
From: Ekaterina Pavlova <ekaterina.pavlova at oracle.com>
Sent: Thursday, August 23, 2018 1:49:56 PM
To: Zhongwei Yao; hotspot-dev; graal-dev at openjdk.java.net
Cc: nd
Subject: Re: Fw: Where to find the 3rd party libraries used by --with-graalunit-lib

Hi Zhongwei,

Please see test/hotspot/jtreg/compiler/graalunit/README.md

Regards,
-katya

On 8/22/18 6:39 PM, Zhongwei Yao wrote:
> Hi, all, could you point out where to find the graalunit-lib path?
>
> --
> Best regards,
> Zhongwei
>
> ________________________________________
> From: Zhongwei Yao
> Sent: Tuesday, August 21, 2018 6:56 PM
> To: build-dev at openjdk.java.net
> Cc: nd
> Subject: Where to find the 3rd party libraries used by --with-graalunit-lib
>
> Hi, all,
>
> To run Graal unit test included in OpenJDK's jtreg tests, I need to add "-with-graalunit-lib" to specify the graalunit-lib path. But I can't find where I can get such libs. Could you point me to where or how to get them? Thanks!
>
> --
> Best regards,
> Zhongwei
>


From jean-philippe.halimi at intel.com  Mon Aug 27 16:18:40 2018
From: jean-philippe.halimi at intel.com (Halimi, Jean-Philippe)
Date: Mon, 27 Aug 2018 16:18:40 +0000
Subject: Code Sequence Matching in Graal
Message-ID: <E55B315EE3E2AA479F9915DAEECA2423451BD3B0@ORSMSX116.amr.corp.intel.com>

Dear all,



I'd like to share my diagnosis with respect to what needs to be done to add new BMI instructions in Graal. Typically, BMI instructions replace specific code sequences for performance purposes.



Currently implemented BMI instructions are invoke intrinsics: they will replace method invokes by the appropriate x86 instruction. They are matched during a method's graph building process. For instance, the following code will match LZCNT:



if (arch.getFeatures().contains(AMD64.CPUFeature.LZCNT) && arch.getFlags().contains(AMD64.Flag.UseCountLeadingZerosInstruction)) {

            r.register1("numberOfLeadingZeros", type, new InvocationPlugin() {

                @Override

                public boolean apply(GraphBuilderContext b, ResolvedJavaMethod targetMethod, Receiver receiver, ValueNode value) {

                    ValueNode folded = AMD64CountLeadingZerosNode.tryFold(value);

                    if (folded != null) {

                       b.addPush(JavaKind.Int, folded);

                    } else {

                        b.addPush(JavaKind.Int, new AMD64CountLeadingZerosNode(value));

                    }

                    return true;

                }

            });

        }



The "numberOfLeadingZeros" method will then be replaced by LZCNT instruction (embedded in AMD64CountLeadingZerosNode) if possible.



Now, for the rest of the instructions we want to support (ANDN, BLSI, BLSMSK and BLSR), there are no invokes that correspond to the instructions. Therefore, we want to do a graph parsing to detect specific patterns that match the instructions we want to support. For instance, for ANDN, we may want to match the following pattern:



Mov r0, 0x0

Load r1, val

Sub r0, r0, r1

And r2, r1, r0



Additionally, I have not found a graph traversal infrastructure that would allow us to do pattern matching. Do we agree that we need such capability in Graal in order to move forward with this? We could, for instance, add a new compiler pass that would match specific patterns.



I'd like to hear your thoughts first as this is my first significant contribution to the project. :-)



Thanks,



Jp



From gilles.m.duboscq at oracle.com  Mon Aug 27 20:10:22 2018
From: gilles.m.duboscq at oracle.com (Gilles Duboscq)
Date: Mon, 27 Aug 2018 22:10:22 +0200
Subject: Code Sequence Matching in Graal
In-Reply-To: <E55B315EE3E2AA479F9915DAEECA2423451BD3B0@ORSMSX116.amr.corp.intel.com>
References: <E55B315EE3E2AA479F9915DAEECA2423451BD3B0@ORSMSX116.amr.corp.intel.com>
Message-ID: <54185554-323d-2924-0da9-c53a77897c0c@oracle.com>

Hi Jean-Philippe,

This kind of matching is typically done during the HIR to LIR transition.
For example see the AMD64NodeMatchRules class e.g.,

```
@MatchRule("(Or (LeftShift=lshift value Constant) (UnsignedRightShift=rshift value Constant))")
public ComplexMatchResult rotateLeftConstant(LeftShiftNode lshift, UnsignedRightShiftNode rshift) {
    if ((lshift.getShiftAmountMask() & (lshift.getY().asJavaConstant().asInt() + rshift.getY().asJavaConstant().asInt())) == 0) {
        return builder -> getArithmeticLIRGenerator().emitRol(operand(lshift.getX()), operand(lshift.getY()));
    }
    return null;
}
```

This rule is used to detect and emit "rotate" patterns to take advantage of the `rol` x86 instruction.
You can see the "s-expression" language used to match parts of the graph.
The code in the rule can then further inspect the HIR nodes to decide to do the special handling or not.

For ANDN i could imagine something like:

```
@MatchRule("(And a (Not b)")
@MatchRule("(And (Not b) a")
public ComplexMatchResult andNot(ValueNode a, ValueNode b) {
    return builder -> getArithmeticLIRGenerator().emitAndNot(operand(a), operand(b));
}
```

Note that i used 2 rules to capture the commutative case.
(`emitAndNot` does not exist, you would have to implement it)

Note that Yudi currently has a PR that adds some of the code needed to emit those BMI instructions in the assembler (just the assembler part though, nothing for matching or generating the LIR).

I hope this helps.
 Gilles

On 27/08/18 18:18, Halimi, Jean-Philippe wrote:
> Dear all,
> 
> 
> 
> I'd like to share my diagnosis with respect to what needs to be done to add new BMI instructions in Graal. Typically, BMI instructions replace specific code sequences for performance purposes.
> 
> 
> 
> Currently implemented BMI instructions are invoke intrinsics: they will replace method invokes by the appropriate x86 instruction. They are matched during a method's graph building process. For instance, the following code will match LZCNT:
> 
> 
> 
> if (arch.getFeatures().contains(AMD64.CPUFeature.LZCNT) && arch.getFlags().contains(AMD64.Flag.UseCountLeadingZerosInstruction)) {
> 
>             r.register1("numberOfLeadingZeros", type, new InvocationPlugin() {
> 
>                 @Override
> 
>                 public boolean apply(GraphBuilderContext b, ResolvedJavaMethod targetMethod, Receiver receiver, ValueNode value) {
> 
>                     ValueNode folded = AMD64CountLeadingZerosNode.tryFold(value);
> 
>                     if (folded != null) {
> 
>                        b.addPush(JavaKind.Int, folded);
> 
>                     } else {
> 
>                         b.addPush(JavaKind.Int, new AMD64CountLeadingZerosNode(value));
> 
>                     }
> 
>                     return true;
> 
>                 }
> 
>             });
> 
>         }
> 
> 
> 
> The "numberOfLeadingZeros" method will then be replaced by LZCNT instruction (embedded in AMD64CountLeadingZerosNode) if possible.
> 
> 
> 
> Now, for the rest of the instructions we want to support (ANDN, BLSI, BLSMSK and BLSR), there are no invokes that correspond to the instructions. Therefore, we want to do a graph parsing to detect specific patterns that match the instructions we want to support. For instance, for ANDN, we may want to match the following pattern:
> 
> 
> 
> Mov r0, 0x0
> 
> Load r1, val
> 
> Sub r0, r0, r1
> 
> And r2, r1, r0
> 
> 
> 
> Additionally, I have not found a graph traversal infrastructure that would allow us to do pattern matching. Do we agree that we need such capability in Graal in order to move forward with this? We could, for instance, add a new compiler pass that would match specific patterns.
> 
> 
> 
> I'd like to hear your thoughts first as this is my first significant contribution to the project. :-)
> 
> 
> 
> Thanks,
> 
> 
> 
> Jp
> 
> 

From yudi.zheng at oracle.com  Wed Aug 29 08:25:00 2018
From: yudi.zheng at oracle.com (Yudi Zheng)
Date: Wed, 29 Aug 2018 10:25:00 +0200
Subject: Code Sequence Matching in Graal
In-Reply-To: <54185554-323d-2924-0da9-c53a77897c0c@oracle.com>
References: <E55B315EE3E2AA479F9915DAEECA2423451BD3B0@ORSMSX116.amr.corp.intel.com>
 <54185554-323d-2924-0da9-c53a77897c0c@oracle.com>
Message-ID: <90349572-1A04-4B07-9C0F-1EE5D05C24A6@oracle.com>

Hi Jean-Philippe,

Please note that the assembler change is in: https://github.com/oracle/graal/commit/0b62c0c86c97286782c2e4c582d07d36f117c00e <https://github.com/oracle/graal/commit/0b62c0c86c97286782c2e4c582d07d36f117c00e>

Best regards,
-Yudi

> On 27 Aug 2018, at 22:10, Gilles Duboscq <gilles.m.duboscq at oracle.com> wrote:
> 
> Hi Jean-Philippe,
> 
> This kind of matching is typically done during the HIR to LIR transition.
> For example see the AMD64NodeMatchRules class e.g.,
> 
> ```
> @MatchRule("(Or (LeftShift=lshift value Constant) (UnsignedRightShift=rshift value Constant))")
> public ComplexMatchResult rotateLeftConstant(LeftShiftNode lshift, UnsignedRightShiftNode rshift) {
>    if ((lshift.getShiftAmountMask() & (lshift.getY().asJavaConstant().asInt() + rshift.getY().asJavaConstant().asInt())) == 0) {
>        return builder -> getArithmeticLIRGenerator().emitRol(operand(lshift.getX()), operand(lshift.getY()));
>    }
>    return null;
> } 
> ```
> 
> This rule is used to detect and emit "rotate" patterns to take advantage of the `rol` x86 instruction.
> You can see the "s-expression" language used to match parts of the graph.
> The code in the rule can then further inspect the HIR nodes to decide to do the special handling or not.
> 
> For ANDN i could imagine something like:
> 
> ```
> @MatchRule("(And a (Not b)")
> @MatchRule("(And (Not b) a")
> public ComplexMatchResult andNot(ValueNode a, ValueNode b) {
>    return builder -> getArithmeticLIRGenerator().emitAndNot(operand(a), operand(b));
> }
> ```
> 
> Note that i used 2 rules to capture the commutative case.
> (`emitAndNot` does not exist, you would have to implement it)
> 
> Note that Yudi currently has a PR that adds some of the code needed to emit those BMI instructions in the assembler (just the assembler part though, nothing for matching or generating the LIR).
> 
> I hope this helps.
> Gilles
> 
> On 27/08/18 18:18, Halimi, Jean-Philippe wrote:
>> Dear all,
>> 
>> 
>> 
>> I'd like to share my diagnosis with respect to what needs to be done to add new BMI instructions in Graal. Typically, BMI instructions replace specific code sequences for performance purposes.
>> 
>> 
>> 
>> Currently implemented BMI instructions are invoke intrinsics: they will replace method invokes by the appropriate x86 instruction. They are matched during a method's graph building process. For instance, the following code will match LZCNT:
>> 
>> 
>> 
>> if (arch.getFeatures().contains(AMD64.CPUFeature.LZCNT) && arch.getFlags().contains(AMD64.Flag.UseCountLeadingZerosInstruction)) {
>> 
>>            r.register1("numberOfLeadingZeros", type, new InvocationPlugin() {
>> 
>>                @Override
>> 
>>                public boolean apply(GraphBuilderContext b, ResolvedJavaMethod targetMethod, Receiver receiver, ValueNode value) {
>> 
>>                    ValueNode folded = AMD64CountLeadingZerosNode.tryFold(value);
>> 
>>                    if (folded != null) {
>> 
>>                       b.addPush(JavaKind.Int, folded);
>> 
>>                    } else {
>> 
>>                        b.addPush(JavaKind.Int, new AMD64CountLeadingZerosNode(value));
>> 
>>                    }
>> 
>>                    return true;
>> 
>>                }
>> 
>>            });
>> 
>>        }
>> 
>> 
>> 
>> The "numberOfLeadingZeros" method will then be replaced by LZCNT instruction (embedded in AMD64CountLeadingZerosNode) if possible.
>> 
>> 
>> 
>> Now, for the rest of the instructions we want to support (ANDN, BLSI, BLSMSK and BLSR), there are no invokes that correspond to the instructions. Therefore, we want to do a graph parsing to detect specific patterns that match the instructions we want to support. For instance, for ANDN, we may want to match the following pattern:
>> 
>> 
>> 
>> Mov r0, 0x0
>> 
>> Load r1, val
>> 
>> Sub r0, r0, r1
>> 
>> And r2, r1, r0
>> 
>> 
>> 
>> Additionally, I have not found a graph traversal infrastructure that would allow us to do pattern matching. Do we agree that we need such capability in Graal in order to move forward with this? We could, for instance, add a new compiler pass that would match specific patterns.
>> 
>> 
>> 
>> I'd like to hear your thoughts first as this is my first significant contribution to the project. :-)
>> 
>> 
>> 
>> Thanks,
>> 
>> 
>> 
>> Jp
>> 
>>