From gfrost at openjdk.org  Sun Dec  1 13:33:46 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Sun, 1 Dec 2024 13:33:46 GMT
Subject: git: openjdk/babylon: code-reflection: More jextract prep
Message-ID: <a8f87613-908d-4936-8bda-3113ea798303@openjdk.org>

Changeset: e40d8a3e
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2024-12-01 13:32:43 +0000
URL:       https://git.openjdk.org/babylon/commit/e40d8a3e1144592ee784136f67cf75f18df30b89

More jextract prep

! hat/bld
! hat/bldr/Bldr.java
! hat/bldr/MavenStyleRepository.java
! hat/bldr/XMLNode.java
! hat/clean


From gfrost at openjdk.org  Sun Dec  1 13:36:36 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Sun, 1 Dec 2024 13:36:36 GMT
Subject: [code-reflection] Integrated: More jextract prep
Message-ID: <vkUbzImS-UwKyQ-uKQJmp7NPVbi7iPE_eyiTqhOtAkw=.0fd4845b-b5a1-4bbc-a157-32f461e69069@github.com>

As we move towards creating a jextracted opencl and cuda backends we need bld changes to support using jextract.

This is step one in that process.

-------------

Commit messages:
 - More jextract prep

Changes: https://git.openjdk.org/babylon/pull/287/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=287&range=00
  Stats: 2865 lines in 5 files changed: 1250 ins; 1108 del; 507 mod
  Patch: https://git.openjdk.org/babylon/pull/287.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/287/head:pull/287

PR: https://git.openjdk.org/babylon/pull/287

From gfrost at openjdk.org  Sun Dec  1 13:36:37 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Sun, 1 Dec 2024 13:36:37 GMT
Subject: [code-reflection] Integrated: More jextract prep
In-Reply-To: <vkUbzImS-UwKyQ-uKQJmp7NPVbi7iPE_eyiTqhOtAkw=.0fd4845b-b5a1-4bbc-a157-32f461e69069@github.com>
References: <vkUbzImS-UwKyQ-uKQJmp7NPVbi7iPE_eyiTqhOtAkw=.0fd4845b-b5a1-4bbc-a157-32f461e69069@github.com>
Message-ID: <InqEsmDqofKVQWTP0e8YYaGVxINsNwHnEMmf8lmFU1o=.c1e4f356-1638-4b4f-bcc5-d5a5b0ebf98d@github.com>

On Sun, 1 Dec 2024 13:31:01 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> As we move towards creating a jextracted opencl and cuda backends we need bld changes to support using jextract.
> 
> This is step one in that process.

This pull request has now been integrated.

Changeset: e40d8a3e
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/e40d8a3e1144592ee784136f67cf75f18df30b89
Stats:     2865 lines in 5 files changed: 1250 ins; 1108 del; 507 mod

More jextract prep

-------------

PR: https://git.openjdk.org/babylon/pull/287

From gfrost at openjdk.org  Mon Dec  2 12:35:51 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Mon, 2 Dec 2024 12:35:51 GMT
Subject: git: openjdk/babylon: code-reflection: Added hatless nbody example
Message-ID: <ec01fa62-48fb-4211-b3ae-6d506c0424bf@openjdk.org>

Changeset: ee2789e1
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2024-12-02 12:34:33 +0000
URL:       https://git.openjdk.org/babylon/commit/ee2789e1ed0aabf629ddd75e5424bd5346ce3f4a

Added hatless nbody example

! hat/.gitignore
! hat/bld
! hat/bldr/Bldr.java
+ hat/bldr/hatlessrun
+ hat/hatless-examples/nbody/.gitignore
+ hat/hatless-examples/nbody/src/main/java/nbody/CLWrap.java
+ hat/hatless-examples/nbody/src/main/java/nbody/GLWrap.java
+ hat/hatless-examples/nbody/src/main/java/nbody/Main.java
+ hat/hatless-examples/nbody/src/main/resources/particle.png
+ hat/hatlessrun


From gfrost at openjdk.org  Mon Dec  2 12:37:39 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Mon, 2 Dec 2024 12:37:39 GMT
Subject: [code-reflection] Integrated: Added hatless nbody example
Message-ID: <WN-4II_UjB1IYPTTa0Q6pOEfV6N3VOAj_5Q6pNqy1cc=.83fcf807-c976-49df-adcf-e449a1375e7e@github.com>

Mainly this allows us to test jextract and to compare numbers against an eventual hat implementation
 
 We are also setting the stage forn opencl backend implementation leaning on the extracted opencl.
 
 You will need to modify bld to jextract opencl and opengl  
 
 ```
 java @bldr/hatlessrun nbody
 ```

-------------

Commit messages:
 - Added hatless nbody example to test jextract and to compare numbers against hat implementation

Changes: https://git.openjdk.org/babylon/pull/288/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=288&range=00
  Stats: 1236 lines in 10 files changed: 1233 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/babylon/pull/288.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/288/head:pull/288

PR: https://git.openjdk.org/babylon/pull/288

From gfrost at openjdk.org  Mon Dec  2 12:37:41 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Mon, 2 Dec 2024 12:37:41 GMT
Subject: [code-reflection] Integrated: Added hatless nbody example
In-Reply-To: <WN-4II_UjB1IYPTTa0Q6pOEfV6N3VOAj_5Q6pNqy1cc=.83fcf807-c976-49df-adcf-e449a1375e7e@github.com>
References: <WN-4II_UjB1IYPTTa0Q6pOEfV6N3VOAj_5Q6pNqy1cc=.83fcf807-c976-49df-adcf-e449a1375e7e@github.com>
Message-ID: <h3Nlg5nHsATEnxPSJa3DKmfnEwP5Rb9ZbQfYOLqJEus=.a4a1426d-40cb-4995-9428-a57b15bda3ef@github.com>

On Mon, 2 Dec 2024 12:32:24 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> Mainly this allows us to test jextract and to compare numbers against an eventual hat implementation
>  
>  We are also setting the stage forn opencl backend implementation leaning on the extracted opencl.
>  
>  You will need to modify bld to jextract opencl and opengl  
>  
>  ```
>  java @bldr/hatlessrun nbody
>  ```

This pull request has now been integrated.

Changeset: ee2789e1
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/ee2789e1ed0aabf629ddd75e5424bd5346ce3f4a
Stats:     1236 lines in 10 files changed: 1233 ins; 0 del; 3 mod

Added hatless nbody example

-------------

PR: https://git.openjdk.org/babylon/pull/288

From gfrost at openjdk.org  Mon Dec  2 16:33:16 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Mon, 2 Dec 2024 16:33:16 GMT
Subject: git: openjdk/babylon: code-reflection: Added hat nbody opengl example
Message-ID: <d5d359ac-d6c6-40b9-97ad-183eac7d00f7@openjdk.org>

Changeset: d63c0f76
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2024-12-02 16:30:50 +0000
URL:       https://git.openjdk.org/babylon/commit/d63c0f764e7b5bb5e6b33e4ed9c9f4ed3e0479e8

Added hat nbody opengl example

! hat/bld
= hat/examples/nbody/.gitignore
= hat/examples/nbody/src/main/java/nbody/CLWrap.java
= hat/examples/nbody/src/main/java/nbody/GLWrap.java
+ hat/examples/nbody/src/main/java/nbody/Main.java
= hat/examples/nbody/src/main/resources/particle.png
! hat/hatrun
! hat/intellij/.idea/modules.xml
! hat/mkpoms
! hat/sanity


From gfrost at openjdk.org  Mon Dec  2 16:33:50 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Mon, 2 Dec 2024 16:33:50 GMT
Subject: [code-reflection] Integrated: Added hat nbody opengl example
Message-ID: <NokSlHnTtNYTEWTO2-gIzfXewjDS26UHdjx5fjLCBd4=.b778bbfd-fe92-4af9-a996-4f89e1e59c40@github.com>

Here we have added HAT nbody implementation.  

It does require jextracted opengl and opencl (we can compare jextracted opencl and hat opencl).

hatrun updated to run nbody. 

Can't build nbody with maven yet.    


. ./env.bash
#We need to add jexract to PATH
export PATH=/Users/you/jextract-22/bin:${PATH}
java @bldr/bld 
java @bldr/hatrun opencl nbody

-------------

Commit messages:
 - Added hat nbody opengl example

Changes: https://git.openjdk.org/babylon/pull/289/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=289&range=00
  Stats: 553 lines in 10 files changed: 535 ins; 13 del; 5 mod
  Patch: https://git.openjdk.org/babylon/pull/289.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/289/head:pull/289

PR: https://git.openjdk.org/babylon/pull/289

From gfrost at openjdk.org  Mon Dec  2 16:33:51 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Mon, 2 Dec 2024 16:33:51 GMT
Subject: [code-reflection] Integrated: Added hat nbody opengl example
In-Reply-To: <NokSlHnTtNYTEWTO2-gIzfXewjDS26UHdjx5fjLCBd4=.b778bbfd-fe92-4af9-a996-4f89e1e59c40@github.com>
References: <NokSlHnTtNYTEWTO2-gIzfXewjDS26UHdjx5fjLCBd4=.b778bbfd-fe92-4af9-a996-4f89e1e59c40@github.com>
Message-ID: <dTsEN4XBgZC-IR7FxHcid_Zzl14z4wvb_GgH8nD7-2U=.ab89c2bc-4438-4b3a-aff4-bef7987cb719@github.com>

On Mon, 2 Dec 2024 16:28:33 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> Here we have added HAT nbody implementation.  
> 
> It does require jextracted opengl and opencl (we can compare jextracted opencl and hat opencl).
> 
> hatrun updated to run nbody. 
> 
> Can't build nbody with maven yet.    
> 
> 
> . ./env.bash
> #We need to add jexract to PATH
> export PATH=/Users/you/jextract-22/bin:${PATH}
> java @bldr/bld 
> java @bldr/hatrun opencl nbody

This pull request has now been integrated.

Changeset: d63c0f76
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/d63c0f764e7b5bb5e6b33e4ed9c9f4ed3e0479e8
Stats:     553 lines in 10 files changed: 535 ins; 13 del; 5 mod

Added hat nbody opengl example

-------------

PR: https://git.openjdk.org/babylon/pull/289

From asotona at openjdk.org  Wed Dec  4 10:56:39 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 4 Dec 2024 10:56:39 GMT
Subject: [code-reflection] RFR: Code model attribute hard-coded
Message-ID: <QQaTWRIIQA4D98a6y8ID_ARn0s5xsE7tjHf6pAK9XZI=.78066b6d-74f1-4228-a2b9-196a2d78d0ee@github.com>

This is yet another experimental serialization of code model into a custom method attribute.
It is based on #282 with all the ops tagged and hard-coded and a bit better utilization of constant pool.

Proportional size of the custom attributes vs. text-encoded fields is 21% (16% of the CP entries).

-------------

Commit messages:
 - code cleanup
 - code cleanup
 - Hard-coded CodeModelAttribute work in progress
 - Hard-coded CodeModelAttribute work in progress
 - Hard-coded CodeModelAttribute work in progress
 - Hard-coded CodeModelAttribute work in progress
 - Hard-coded CodeModelAttribute work in progress
 - typo
 - CodeModelAttribute structure cleanup + javadoc work in progress
 - CodeModeAtrtribute documentation work in progress
 - ... and 7 more: https://git.openjdk.org/babylon/compare/9afe3b74...7a94d8db

Changes: https://git.openjdk.org/babylon/pull/290/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=290&range=00
  Stats: 1099 lines in 6 files changed: 1093 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/babylon/pull/290.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/290/head:pull/290

PR: https://git.openjdk.org/babylon/pull/290

From asotona at openjdk.org  Wed Dec  4 11:01:39 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 4 Dec 2024 11:01:39 GMT
Subject: [code-reflection] RFR: Code model attribute hard-coded [v2]
In-Reply-To: <QQaTWRIIQA4D98a6y8ID_ARn0s5xsE7tjHf6pAK9XZI=.78066b6d-74f1-4228-a2b9-196a2d78d0ee@github.com>
References: <QQaTWRIIQA4D98a6y8ID_ARn0s5xsE7tjHf6pAK9XZI=.78066b6d-74f1-4228-a2b9-196a2d78d0ee@github.com>
Message-ID: <tJqC99N3giOBMnQnh9cV-8MmAb6vL7c51wJFc6wmYYg=.f424dc50-b4ce-42a5-abb5-69582aa359bb@github.com>

> This is yet another experimental serialization of code model into a custom method attribute.
> It is based on #282 with all the ops tagged and hard-coded and a bit better utilization of constant pool.
> 
> Proportional size of the custom attributes vs. text-encoded fields is 21% (16% of the CP entries).

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  code cleanup

-------------

Changes:
  - all: https://git.openjdk.org/babylon/pull/290/files
  - new: https://git.openjdk.org/babylon/pull/290/files/7a94d8db..15f241e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=290&range=01
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=290&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/babylon/pull/290.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/290/head:pull/290

PR: https://git.openjdk.org/babylon/pull/290

From gfrost at openjdk.org  Wed Dec  4 11:06:58 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Wed, 4 Dec 2024 11:06:58 GMT
Subject: git: openjdk/babylon: code-reflection: Hat add jextract to maven
Message-ID: <95d3d0bf-c308-44f0-acc5-c353d97493ac@openjdk.org>

Changeset: 5deaf0fd
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2024-12-04 11:05:15 +0000
URL:       https://git.openjdk.org/babylon/commit/5deaf0fd58d7ad0975c508e2164c9057817c77d8

Hat add jextract to maven

! hat/backends/cuda/pom.xml
! hat/backends/hip/pom.xml
! hat/backends/mock/pom.xml
! hat/backends/opencl/pom.xml
! hat/backends/pom.xml
! hat/backends/ptx/pom.xml
! hat/backends/spirv/pom.xml
! hat/bldr/Bldr.java
! hat/bldr/XMLNode.java
! hat/docs/hat-01-03-building-hat-with-maven.md
! hat/examples/blackscholes/pom.xml
! hat/examples/experiments/pom.xml
! hat/examples/heal/pom.xml
! hat/examples/life/pom.xml
! hat/examples/mandel/pom.xml
! hat/examples/squares/pom.xml
! hat/examples/violajones/pom.xml
+ hat/extractions/.gitignore
+ hat/extractions/opencl/.gitignore
+ hat/extractions/opencl/pom.xml
+ hat/extractions/opengl/.gitignore
+ hat/extractions/opengl/pom.xml
+ hat/extractions/pom.xml
! hat/hat/pom.xml
+ hat/intellij/nbody.iml
! hat/mkpoms
! hat/pom.xml


From gfrost at openjdk.org  Wed Dec  4 11:08:30 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Wed, 4 Dec 2024 11:08:30 GMT
Subject: [code-reflection] Integrated: Hat add jextract to maven
Message-ID: <ej2-uZGIl2HfVYL17MVyIgVUNBhDDaeUgYmKgommch4=.dbee11cf-0757-4660-ad9b-0d048e89cd69@github.com>

Previously we modified the bld to use jextract, here we updated the mkpoms script to generate maven equiv code. 

So 

. ./env.bash 
java @bldr/mkpoms
mvn -e clean compile jar:jar install

Should create backends and examples and extract opencl and opengl for nbody example.

-------------

Commit messages:
 - swap hat.target for hat.build in pom.xmls and cleanup mkpoms
 - mkpoms now generates jextract capable pom.xml files
 - pommaker now works with extractions

Changes: https://git.openjdk.org/babylon/pull/291/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=291&range=00
  Stats: 486 lines in 27 files changed: 329 ins; 14 del; 143 mod
  Patch: https://git.openjdk.org/babylon/pull/291.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/291/head:pull/291

PR: https://git.openjdk.org/babylon/pull/291

From gfrost at openjdk.org  Wed Dec  4 11:08:31 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Wed, 4 Dec 2024 11:08:31 GMT
Subject: [code-reflection] Integrated: Hat add jextract to maven
In-Reply-To: <ej2-uZGIl2HfVYL17MVyIgVUNBhDDaeUgYmKgommch4=.dbee11cf-0757-4660-ad9b-0d048e89cd69@github.com>
References: <ej2-uZGIl2HfVYL17MVyIgVUNBhDDaeUgYmKgommch4=.dbee11cf-0757-4660-ad9b-0d048e89cd69@github.com>
Message-ID: <--PWCntwRMG4k5NN0FPhnmZuTVvQi3maALgIrBXlIjs=.bb51b9f6-5108-4d24-9341-ec4e38bf106d@github.com>

On Wed, 4 Dec 2024 11:02:53 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> Previously we modified the bld to use jextract, here we updated the mkpoms script to generate maven equiv code. 
> 
> So 
> 
> . ./env.bash 
> java @bldr/mkpoms
> mvn -e clean compile jar:jar install
> 
> Should create backends and examples and extract opencl and opengl for nbody example.

This pull request has now been integrated.

Changeset: 5deaf0fd
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/5deaf0fd58d7ad0975c508e2164c9057817c77d8
Stats:     486 lines in 27 files changed: 329 ins; 14 del; 143 mod

Hat add jextract to maven

-------------

PR: https://git.openjdk.org/babylon/pull/291

From mcimadamore at openjdk.org  Wed Dec  4 11:15:57 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 4 Dec 2024 11:15:57 GMT
Subject: [code-reflection] RFR: Code model attribute hard-coded [v2]
In-Reply-To: <tJqC99N3giOBMnQnh9cV-8MmAb6vL7c51wJFc6wmYYg=.f424dc50-b4ce-42a5-abb5-69582aa359bb@github.com>
References: <QQaTWRIIQA4D98a6y8ID_ARn0s5xsE7tjHf6pAK9XZI=.78066b6d-74f1-4228-a2b9-196a2d78d0ee@github.com>
 <tJqC99N3giOBMnQnh9cV-8MmAb6vL7c51wJFc6wmYYg=.f424dc50-b4ce-42a5-abb5-69582aa359bb@github.com>
Message-ID: <n6LDBKrYbiQn6U8t0hLKAGQ1XQmiw3TYaZTFjf0cDWs=.b988e3cc-be77-4f50-a78c-30210ff2cab6@github.com>

On Wed, 4 Dec 2024 11:01:39 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This is yet another experimental serialization of code model into a custom method attribute.
>> It is based on #282 with all the ops tagged and hard-coded and a bit better utilization of constant pool.
>> 
>> Compiled size of the BytecodeTest class (with text-encoded code models) is 127531 bytes, CP contains 1612 entries.
>> Cleaned size of the class (removed text-encoded code models and their static initialization) is 39044 bytes, CP contains 1277 entries.
>> Size with models encoded in custom attributes is 57206 bytes, CP contains 1452 entries.
>> 
>> Proportional size of the custom attributes vs. text-encoded fields is 21% (52% of the CP entries).
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code cleanup

src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/CodeModelAttribute.java line 37:

> 35: public class CodeModelAttribute extends CustomAttribute<CodeModelAttribute>{
> 36: 
> 37:     enum Tag {

In terms of maintenance, I wonder if there could be a way to connect the tag more directly to the op classes. E.g. so that if an op is added/removed, we may rely on static checks to detect that our reading/writing logic needs updating.

But maybe that works already: after all, the writing logic does a switch on the `op` instance - if that switch is made exhaustive, we could prevent mistakes when new ops are added. (when ops are removed, the mistake will be detected more easily, as the serialization code will refer to no longer existing classes).

-------------

PR Review Comment: https://git.openjdk.org/babylon/pull/290#discussion_r1869262885

From mcimadamore at openjdk.org  Wed Dec  4 11:49:50 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 4 Dec 2024 11:49:50 GMT
Subject: [code-reflection] RFR: Code model attribute [v4]
In-Reply-To: <YtTPIbKQa6BpQcygZJ88ehpEaowbdiktLs2yLJaQwRI=.cc35e50c-503e-44b5-8def-28b286db09c5@github.com>
References: <4DTu5qIAm7hkWSrw0rRyDA_nBPpM1FFPsXIF0lk1wTk=.73d926df-53eb-4565-861e-2d0a9ba03574@github.com>
 <YtTPIbKQa6BpQcygZJ88ehpEaowbdiktLs2yLJaQwRI=.cc35e50c-503e-44b5-8def-28b286db09c5@github.com>
Message-ID: <jS6L79cENH-XoEAINvX51wY4hrWAHB5ypYDmuAYmZFI=.8b4e3d9a-2992-46c3-8788-391e9330120a@github.com>

On Wed, 27 Nov 2024 08:53:39 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This is experimental serialization of code model into a custom method attribute.
>> 
>> I've performed brief comparison on `BytecodeTest` as a representant of class with majority of methods annotated with `@CodeReflection`.
>> 
>> Compiled size of the `BytecodeTest` class (with text-encoded code models) is 121288 bytes, CP contains 1612 entries.
>> Cleaned size of the class (removed text-encoded code models and their static initialization) is 32801 bytes, CP contains 1277 entries.
>> Size with models encoded in custom attributes is 74541 bytes, CP contains 1435 entries.
>> 
>> Proportional size of the custom attributes vs. text-encoded fields is 37% (47% of the CP entries).
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

<removed>

-------------

PR Review: https://git.openjdk.org/babylon/pull/282#pullrequestreview-2478312197

From gfrost at openjdk.org  Fri Dec  6 13:24:46 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Fri, 6 Dec 2024 13:24:46 GMT
Subject: git: openjdk/babylon: code-reflection: Add platform capability checks
 to bld and mkpoms
Message-ID: <35e8005e-f0b2-4bae-b724-1bcbc62f765a@openjdk.org>

Changeset: 8abfd954
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2024-12-06 13:24:11 +0000
URL:       https://git.openjdk.org/babylon/commit/8abfd95442f999a60dc960fb164c69107ae84644

Add platform capability checks to bld and mkpoms

! hat/bld
! hat/bldr/Bldr.java
+ hat/bldr/CMakeProbe.java
+ hat/bldr/Capabilities.java
+ hat/bldr/Regex.java
! hat/bldr/XMLNode.java
! hat/examples/nbody/src/main/java/nbody/CLWrap.java
! hat/mkpoms


From gfrost at openjdk.org  Fri Dec  6 13:27:34 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Fri, 6 Dec 2024 13:27:34 GMT
Subject: [code-reflection] Integrated: Add platform capability checks to bld
 and mkpoms
Message-ID: <a6-FYUQFhHvwsJeEMmiuUbn2dPpi3XgWanAQVyP9-1I=.1e2fa6d2-c3e0-4d41-b967-4abf9ea721e0@github.com>

Added platform capability checking to bld and mkpoms

This allows the build to determine if the platform say has OpenCL/CUDA/OpenGL etc. 

We piggy back on cmake to do this. via CMakeProbe class.

We pass the list of requested capabilities to CMakeProbe,  which builds a simple CMakeLists.txt, executes and extracts its state (basically collects all of the CMake internal Vars). The vars are passed to each capability and individual cababilities can use these vars to determine whether the capabity exists, and to determine usefil unfi (where are the header files for OpenCL for instance).

So now nbody example (which needs opencl and opengl extracted via jextract) will only attempt to build on platforms with these capabilities. 

In future we may need to support capabities that cmake can't help us with.  Such as HIP

-------------

Commit messages:
 - Add platform capability checks to bld and mkpoms

Changes: https://git.openjdk.org/babylon/pull/292/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=292&range=00
  Stats: 1101 lines in 8 files changed: 656 ins; 179 del; 266 mod
  Patch: https://git.openjdk.org/babylon/pull/292.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/292/head:pull/292

PR: https://git.openjdk.org/babylon/pull/292

From gfrost at openjdk.org  Fri Dec  6 13:27:35 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Fri, 6 Dec 2024 13:27:35 GMT
Subject: [code-reflection] Integrated: Add platform capability checks to bld
 and mkpoms
In-Reply-To: <a6-FYUQFhHvwsJeEMmiuUbn2dPpi3XgWanAQVyP9-1I=.1e2fa6d2-c3e0-4d41-b967-4abf9ea721e0@github.com>
References: <a6-FYUQFhHvwsJeEMmiuUbn2dPpi3XgWanAQVyP9-1I=.1e2fa6d2-c3e0-4d41-b967-4abf9ea721e0@github.com>
Message-ID: <iAueosuwhIWCAS3pJdtVR8Z57xStBumeE4uryuEsi1w=.d9d50fb5-cbb4-4f5e-86bf-8de27ff9453d@github.com>

On Fri, 6 Dec 2024 13:22:04 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> Added platform capability checking to bld and mkpoms
> 
> This allows the build to determine if the platform say has OpenCL/CUDA/OpenGL etc. 
> 
> We piggy back on cmake to do this. via CMakeProbe class.
> 
> We pass the list of requested capabilities to CMakeProbe,  which builds a simple CMakeLists.txt, executes and extracts its state (basically collects all of the CMake internal Vars). The vars are passed to each capability and individual cababilities can use these vars to determine whether the capabity exists, and to determine usefil unfi (where are the header files for OpenCL for instance).
> 
> So now nbody example (which needs opencl and opengl extracted via jextract) will only attempt to build on platforms with these capabilities. 
> 
> In future we may need to support capabities that cmake can't help us with.  Such as HIP

This pull request has now been integrated.

Changeset: 8abfd954
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/8abfd95442f999a60dc960fb164c69107ae84644
Stats:     1101 lines in 8 files changed: 656 ins; 179 del; 266 mod

Add platform capability checks to bld and mkpoms

-------------

PR: https://git.openjdk.org/babylon/pull/292

From psandoz at openjdk.org  Fri Dec  6 16:26:04 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 6 Dec 2024 16:26:04 GMT
Subject: [code-reflection] RFR: Integrate Java Triton example with Intel
 Triton Backend [v4]
In-Reply-To: <pVXGQ1LY4daY6IAOZq4dSdOY4AN4r-6JxmWFr8TF0_g=.fa6be527-b69b-41de-bbdc-532a1e7fe122@github.com>
References: <NMe-IE1hpqjx8hpUXBRULL1BXqUjM92QzPQLh0weCx4=.a4d5938d-89f5-4a48-ad25-b912367bf429@github.com>
 <pVXGQ1LY4daY6IAOZq4dSdOY4AN4r-6JxmWFr8TF0_g=.fa6be527-b69b-41de-bbdc-532a1e7fe122@github.com>
Message-ID: <NtiTi99wDUFpgTocYASjAHeHzCwYNNDmkwWYf9HBRf4=.52c0d1b3-8975-4ae3-a91e-d04a7d1527a7@github.com>

On Fri, 8 Nov 2024 22:03:04 GMT, hanklo6 <duke at openjdk.org> wrote:

>> Babylon Java Triton example translates Java source code with Java Triton API into code model by code reflection.
>>  
>> In this PR, we traverse the given code model and output Triton MLIR dialect in the generic form, and then inject generated MLIR dialect into the Intel Triton backend. We then utilize Intel Triton backend to compile the Triton MLIR dialect into a SPIR-V module. Use `Jextract` to create Java binding of Intel Level Zero runtime and launch the given kernel function with it on Intel GPUs.
>> 
>> ## Usage
>> Navigate to the `cr-example/triton` directory and execute `mvn clean test`. This will generate multiple MLIR files in the `result` directory ready to be processed by the Triton backend. 
>> 
>> Next, modify the `compiler.py` file within the `intel-xpu-triton-backend` project by applying the patch `git apply add-mlir-insertion.patch`. Then run the Triton backend by running `python3 translate.py`.
>> 
>> The Triton backend will generate SPIR-V files, which will be located under `~/.triton/cache/{hash_value}/{kernel_name}/{kernel_name}.spv`.
>> 
>> To create a binding for Level Zero, execute the below commands:
>> 
>> $JEXTRACT_DIR/bin/jextract --output src/gen/java -I /usr/include -t oneapi.levelzero level-zero/include/ze_api.h
>> $JAVA_HOME/bin/javac -cp target/classes -d target/classes src/gen/java/oneapi/levelzero/*.java
>> $JAVA_HOME/bin/jar cf levelzero.jar -C target/classes/ .
>> 
>> The will generate `levelzero.jar` in the current directory.
>> 
>> After getting JAR files for Level Zero and `JSON-java`, proceed to compile and run the launcher `LevelZero.java` with the following commands:
>> 
>> babylon/build/linux-x86_64-server-release/jdk/bin/javac -cp .:levelzero.jar:json-java.jar LevelZero.java
>> babylon/build/linux-x86_64-server-release/jdk/bin/java -ea -cp .:levelzero.jar:json-java.jar LevelZero
>> 
>> 
>> Ensure the hash values in`~/.triton/cache` match those used in the `LevelZero.java`.
>> 
>> ## Dependencies
>> - [intel-xpu-backend-for-triton](https://github.com/intel/intel-xpu-backend-for-triton)
>> - [intel-extension-for-pytorch](https://github.com/intel/intel-extension-for-pytorch)
>> - [Intel oneAPI base Toolkit](https://www.intel.com/content/www/us/en/developer/tools/oneapi/base-toolkit-download.html)
>> - [Jextract](https://github.com/openjdk/jextract)
>> - [Level Zero loader](https://github.com/oneapi-src/level-zero)
>> - [compute-runtime](https://github.com/intel/compute-runtime/releases)
>> - [JSON-java](https://github.com/stleary/JSON-java)
>
> hanklo6 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add the test for matrix multiplication with float16

Keep alive, need to give it another quick review.

-------------

PR Comment: https://git.openjdk.org/babylon/pull/241#issuecomment-2523671215

From gfrost at openjdk.org  Fri Dec  6 18:12:27 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Fri, 6 Dec 2024 18:12:27 GMT
Subject: git: openjdk/babylon: code-reflection: Removed hard coded jextract
 path
Message-ID: <6333f965-9ead-4f5f-86cb-44806ecc19df@openjdk.org>

Changeset: 2d6b5763
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2024-12-06 18:11:07 +0000
URL:       https://git.openjdk.org/babylon/commit/2d6b5763e4bdcec7bf12760071198b0322479195

Removed hard coded jextract path

! hat/bld
! hat/bldr/Bldr.java


From gfrost at openjdk.org  Fri Dec  6 18:14:07 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Fri, 6 Dec 2024 18:14:07 GMT
Subject: [code-reflection] Integrated: Removed hard coded jextract path
In-Reply-To: <zAq5aOP4Gcea2A8of22EQZ9wkfo4xX4ZgPBzdLcu6_Y=.ee59ad0c-16f8-47df-8ae8-d00269a63c68@github.com>
References: <zAq5aOP4Gcea2A8of22EQZ9wkfo4xX4ZgPBzdLcu6_Y=.ee59ad0c-16f8-47df-8ae8-d00269a63c68@github.com>
Message-ID: <AgA136mVYBdcw2fRGLn25sACa1iJmEhg_IDJcbSQYHo=.a1b308d8-2b10-4f03-ae03-bda4f271ee60@github.com>

On Fri, 6 Dec 2024 18:09:17 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> This fix allows bld to access jextract from user PATH. Rather than hardcoding in the script.

This pull request has now been integrated.

Changeset: 2d6b5763
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/2d6b5763e4bdcec7bf12760071198b0322479195
Stats:     154 lines in 2 files changed: 73 ins; 9 del; 72 mod

Removed hard coded jextract path

-------------

PR: https://git.openjdk.org/babylon/pull/293

From gfrost at openjdk.org  Fri Dec  6 18:14:07 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Fri, 6 Dec 2024 18:14:07 GMT
Subject: [code-reflection] Integrated: Removed hard coded jextract path
Message-ID: <zAq5aOP4Gcea2A8of22EQZ9wkfo4xX4ZgPBzdLcu6_Y=.ee59ad0c-16f8-47df-8ae8-d00269a63c68@github.com>

This fix allows bld to access jextract from user PATH. Rather than hardcoding in the script.

-------------

Commit messages:
 - Removed hard coded jextract path

Changes: https://git.openjdk.org/babylon/pull/293/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=293&range=00
  Stats: 154 lines in 2 files changed: 73 ins; 9 del; 72 mod
  Patch: https://git.openjdk.org/babylon/pull/293.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/293/head:pull/293

PR: https://git.openjdk.org/babylon/pull/293

From mabbay at openjdk.org  Sat Dec  7 10:20:38 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Sat, 7 Dec 2024 10:20:38 GMT
Subject: [code-reflection] RFR: Experiment with replacing textual
 representation in classfile with method that builds the model [v12]
In-Reply-To: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
References: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
Message-ID: <CnIn-irc2gIGHOm38VAEPgWmj9bM5pcbhtaDEMWdQL4=.29d6a5e2-fb91-4d13-b1a8-540255878dce@github.com>

> Experiment with replacing textual representation in classfile with method that builds the model.
> Note: This PR is based on changes from #272.

Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:

  Separate transformation from testing

-------------

Changes:
  - all: https://git.openjdk.org/babylon/pull/274/files
  - new: https://git.openjdk.org/babylon/pull/274/files/f54adb7d..75743ad8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=274&range=11
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=274&range=10-11

  Stats: 440 lines in 11 files changed: 259 ins; 181 del; 0 mod
  Patch: https://git.openjdk.org/babylon/pull/274.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/274/head:pull/274

PR: https://git.openjdk.org/babylon/pull/274

From mabbay at openjdk.org  Sat Dec  7 10:30:41 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Sat, 7 Dec 2024 10:30:41 GMT
Subject: [code-reflection] RFR: Experiment with replacing textual
 representation in classfile with method that builds the model [v13]
In-Reply-To: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
References: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
Message-ID: <R1-nZRDG-CHSpdV4eHhoFdEE9eoU8lNAa8PXVyJQwWE=.38ca3aa9-e12d-430d-8277-a25658c29b68@github.com>

> Experiment with replacing textual representation in classfile with method that builds the model.
> Note: This PR is based on changes from #272.

Mourad Abbay has updated the pull request incrementally with two additional commits since the last revision:

 - Remove unused class
 - ignore transformed classfiles

-------------

Changes:
  - all: https://git.openjdk.org/babylon/pull/274/files
  - new: https://git.openjdk.org/babylon/pull/274/files/75743ad8..4d4c3ba0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=274&range=12
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=274&range=11-12

  Stats: 11 lines in 2 files changed: 2 ins; 9 del; 0 mod
  Patch: https://git.openjdk.org/babylon/pull/274.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/274/head:pull/274

PR: https://git.openjdk.org/babylon/pull/274

From psandoz at openjdk.org  Mon Dec  9 22:28:43 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 9 Dec 2024 22:28:43 GMT
Subject: [code-reflection] RFR: Merge master
Message-ID: <RXIFMR6t6s2KQmV9pYOUBaAVwgW9t6OqKimg5VkroJY=.420a9cc5-188f-4d74-a14b-b473fe689120@github.com>

Merge master

-------------

Commit messages:
 - Merge master
 - 8345803: Update copyright year to 2024 for security in files where it was missed
 - 8344629: SSLSocketNoServerHelloClientShutdown test timeout
 - 8345390: [ubsan] systemDictionaryShared.cpp:964: member call on null pointer
 - 8345794: Backout doc change introduced by JDK-8235786
 - 8345693: Update JCov for class file version 69
 - 8345287: C2: live in computation is broken
 - 8345156: C2: Add bailouts next to a few asserts
 - 8345793: Update copyright year to 2024 for the build system in files where it was missed
 - 8345614: Improve AnnotationFormatError message for duplicate annotation interfaces
 - ... and 1162 more: https://git.openjdk.org/babylon/compare/2d6b5763...05b99261

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - code-reflection: https://webrevs.openjdk.org/?repo=babylon&pr=294&range=00.0
 - master: https://webrevs.openjdk.org/?repo=babylon&pr=294&range=00.1

Changes: https://git.openjdk.org/babylon/pull/294/files
  Stats: 606369 lines in 8352 files changed: 340480 ins; 215618 del; 50271 mod
  Patch: https://git.openjdk.org/babylon/pull/294.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/294/head:pull/294

PR: https://git.openjdk.org/babylon/pull/294

From mabbay at openjdk.org  Tue Dec 10 13:50:22 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Tue, 10 Dec 2024 13:50:22 GMT
Subject: git: openjdk/babylon: code-reflection: Support bytecode generation for
 invocation of varArg method
Message-ID: <8ebde159-2e1e-47f6-b167-1813b522f490@openjdk.org>

Changeset: b99e2711
Branch: code-reflection
Author:    Mourad Abbay <mabbay at openjdk.org>
Date:      2024-12-10 13:49:31 +0000
URL:       https://git.openjdk.org/babylon/commit/b99e27117419db460ec6831c142d8a1146ca9aec

Support bytecode generation for invocation of varArg method

Reviewed-by: psandoz

! src/jdk.incubator.code/share/classes/jdk/incubator/code/bytecode/BytecodeGenerator.java
! src/jdk.incubator.code/share/classes/jdk/incubator/code/op/CoreOp.java
+ test/jdk/java/lang/reflect/code/TestInvokeOp.java
+ test/jdk/java/lang/reflect/code/bytecode/TestVarArg.java


From mabbay at openjdk.org  Tue Dec 10 13:53:28 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Tue, 10 Dec 2024 13:53:28 GMT
Subject: [code-reflection] RFR: Support bytecode generation for invocation
 of varArg method [v5]
In-Reply-To: <uYto4n_V0XZ07xtLfBJbz9h4JgnTGfu08B6tPAqC8WM=.84bb32d5-517b-40a0-a486-693e7071eaca@github.com>
References: <uYto4n_V0XZ07xtLfBJbz9h4JgnTGfu08B6tPAqC8WM=.84bb32d5-517b-40a0-a486-693e7071eaca@github.com>
Message-ID: <Cq12HVic9yqgc8xc-fMvlH3vi0zBSHQoKKPy5uJukWQ=.7615352f-5b38-4038-a4e4-e243cb0ee077@github.com>

> Support bytecode generation for invocation of varArg method.

Mourad Abbay has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Apply suggestion
 - Merge branch 'code-reflection' into bytecode-gen-varArg
 - Add test for long and double
 - Apply Suggestions
 - Add method CoreOp.InvokeOp.argOperands
 - Add test cases for empty var arg, long and double
 - Move code related to InvokeOp from processOperands(Op).
 - Support bytecode generation for invocation of varArg method

-------------

Changes:
  - all: https://git.openjdk.org/babylon/pull/272/files
  - new: https://git.openjdk.org/babylon/pull/272/files/0dfc24a2..79524797

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=272&range=04
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=272&range=03-04

  Stats: 22830 lines in 496 files changed: 13839 ins; 6574 del; 2417 mod
  Patch: https://git.openjdk.org/babylon/pull/272.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/272/head:pull/272

PR: https://git.openjdk.org/babylon/pull/272

From mabbay at openjdk.org  Tue Dec 10 13:53:29 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Tue, 10 Dec 2024 13:53:29 GMT
Subject: [code-reflection] Integrated: Support bytecode generation for
 invocation of varArg method
In-Reply-To: <uYto4n_V0XZ07xtLfBJbz9h4JgnTGfu08B6tPAqC8WM=.84bb32d5-517b-40a0-a486-693e7071eaca@github.com>
References: <uYto4n_V0XZ07xtLfBJbz9h4JgnTGfu08B6tPAqC8WM=.84bb32d5-517b-40a0-a486-693e7071eaca@github.com>
Message-ID: <YV3mrbgL2pLAdzu9vmEyV-YR_MtpCrCZTIGUObME_gk=.593e0a34-481f-46b2-a3c8-b4cd7d28e1ee@github.com>

On Wed, 6 Nov 2024 10:43:58 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> Support bytecode generation for invocation of varArg method.

This pull request has now been integrated.

Changeset: b99e2711
Author:    Mourad Abbay <mabbay at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/b99e27117419db460ec6831c142d8a1146ca9aec
Stats:     190 lines in 4 files changed: 185 ins; 3 del; 2 mod

Support bytecode generation for invocation of varArg method

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.org/babylon/pull/272

From mabbay at openjdk.org  Tue Dec 10 13:56:46 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Tue, 10 Dec 2024 13:56:46 GMT
Subject: [code-reflection] RFR: Experiment with replacing textual
 representation in classfile with method that builds the model [v14]
In-Reply-To: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
References: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
Message-ID: <hMCBh0ubQDrqEXNz81v7FVEqYzX6fttL1XWGuIkoR9g=.cc207774-a500-4d28-908a-3dc2da3d7db9@github.com>

> Experiment with replacing textual representation in classfile with method that builds the model.
> Note: This PR is based on changes from #272.

Mourad Abbay has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 23 additional commits since the last revision:

 - Merge branch 'code-reflection' into ir-builder-expriment
 - Remove unused class
 - ignore transformed classfiles
 - Separate transformation from testing
 - Add script for running text to code builder on hat examples
 - Remove unused method.
 - Write the columns names after all processing is done
 - Write data to csv file
 - Modify the script to run on all compiler tests classes one by one
 - Box value before invoking Map.put
 - ... and 13 more: https://git.openjdk.org/babylon/compare/e8af06ec...2bfd67be

-------------

Changes:
  - all: https://git.openjdk.org/babylon/pull/274/files
  - new: https://git.openjdk.org/babylon/pull/274/files/4d4c3ba0..2bfd67be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=274&range=13
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=274&range=12-13

  Stats: 22825 lines in 496 files changed: 13837 ins; 6572 del; 2416 mod
  Patch: https://git.openjdk.org/babylon/pull/274.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/274/head:pull/274

PR: https://git.openjdk.org/babylon/pull/274

From mabbay at openjdk.org  Tue Dec 10 14:06:15 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Tue, 10 Dec 2024 14:06:15 GMT
Subject: [code-reflection] RFR: Experiment with replacing textual
 representation in classfile with method that builds the model [v15]
In-Reply-To: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
References: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
Message-ID: <jq7jEykW_pY1dEP7wD0CiJKTs8okrROXXGu-JHlAVi4=.eff06cf1-11d0-4a02-aca4-372f03839baf@github.com>

> Experiment with replacing textual representation in classfile with method that builds the model.
> Note: This PR is based on changes from #272.

Mourad Abbay has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:

 - Merge branch 'code-reflection' into ir-builder-expriment
   
   # Conflicts:
   #	src/jdk.incubator.code/share/classes/jdk/incubator/code/bytecode/BytecodeGenerator.java
   #	test/jdk/java/lang/reflect/code/bytecode/TestVarArg.java
 - Merge branch 'code-reflection' into ir-builder-expriment
 - Remove unused class
 - ignore transformed classfiles
 - Separate transformation from testing
 - Add script for running text to code builder on hat examples
 - Remove unused method.
 - Write the columns names after all processing is done
 - Write data to csv file
 - Modify the script to run on all compiler tests classes one by one
 - ... and 14 more: https://git.openjdk.org/babylon/compare/b99e2711...2e11695e

-------------

Changes: https://git.openjdk.org/babylon/pull/274/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=274&range=14
  Stats: 289 lines in 11 files changed: 288 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/babylon/pull/274.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/274/head:pull/274

PR: https://git.openjdk.org/babylon/pull/274

From psandoz at openjdk.org  Tue Dec 10 18:29:04 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 10 Dec 2024 18:29:04 GMT
Subject: [code-reflection] Withdrawn: Merge master
In-Reply-To: <RXIFMR6t6s2KQmV9pYOUBaAVwgW9t6OqKimg5VkroJY=.420a9cc5-188f-4d74-a14b-b473fe689120@github.com>
References: <RXIFMR6t6s2KQmV9pYOUBaAVwgW9t6OqKimg5VkroJY=.420a9cc5-188f-4d74-a14b-b473fe689120@github.com>
Message-ID: <3BaVZfB0S8ks3OBL0FFH6drf1cBWiFwLhgH8vCe6684=.964e26be-0af1-4c4a-9d35-bdbaf7b05011@github.com>

On Mon, 9 Dec 2024 22:22:44 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Merge master

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/babylon/pull/294

From psandoz at openjdk.org  Tue Dec 10 21:45:41 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 10 Dec 2024 21:45:41 GMT
Subject: git: openjdk/babylon: code-reflection: Revert change
Message-ID: <c9c7f3cd-d060-4ef5-a998-daf9f807b2db@openjdk.org>

Changeset: 79cd5cf3
Branch: code-reflection
Author:    Paul Sandoz <psandoz at openjdk.org>
Date:      2024-12-10 21:43:42 +0000
URL:       https://git.openjdk.org/babylon/commit/79cd5cf3388d6ca86f7d3c968b47b19a11e71ebe

Revert change

! make/langtools/build.xml


From psandoz at openjdk.org  Tue Dec 10 21:47:19 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 10 Dec 2024 21:47:19 GMT
Subject: [code-reflection] Integrated: Revert change
Message-ID: <wJuUtpf6DhZmM-IDNUHtDmaH-7sDdpLfK_fen2LHVKc=.638db961-e92d-4538-ab7c-fdf1a7b40d3b@github.com>

Revert as we no longer need to explicitly copy.

-------------

Commit messages:
 - Revert

Changes: https://git.openjdk.org/babylon/pull/295/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=295&range=00
  Stats: 10 lines in 1 file changed: 0 ins; 8 del; 2 mod
  Patch: https://git.openjdk.org/babylon/pull/295.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/295/head:pull/295

PR: https://git.openjdk.org/babylon/pull/295

From psandoz at openjdk.org  Tue Dec 10 21:47:19 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 10 Dec 2024 21:47:19 GMT
Subject: [code-reflection] Integrated: Revert change
In-Reply-To: <wJuUtpf6DhZmM-IDNUHtDmaH-7sDdpLfK_fen2LHVKc=.638db961-e92d-4538-ab7c-fdf1a7b40d3b@github.com>
References: <wJuUtpf6DhZmM-IDNUHtDmaH-7sDdpLfK_fen2LHVKc=.638db961-e92d-4538-ab7c-fdf1a7b40d3b@github.com>
Message-ID: <BCuio7Vez-UDIrD0cfAh2GnA-Sb49rded01KSzlis-g=.d60338c3-c20e-4bdc-afee-5b6a0f452ae3@github.com>

On Tue, 10 Dec 2024 21:41:19 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Revert as we no longer need to explicitly copy.

This pull request has now been integrated.

Changeset: 79cd5cf3
Author:    Paul Sandoz <psandoz at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/79cd5cf3388d6ca86f7d3c968b47b19a11e71ebe
Stats:     10 lines in 1 file changed: 0 ins; 8 del; 2 mod

Revert change

-------------

PR: https://git.openjdk.org/babylon/pull/295

From psandoz at openjdk.org  Tue Dec 10 23:23:57 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 10 Dec 2024 23:23:57 GMT
Subject: [code-reflection] RFR: Integrate Java Triton example with Intel
 Triton Backend [v4]
In-Reply-To: <pVXGQ1LY4daY6IAOZq4dSdOY4AN4r-6JxmWFr8TF0_g=.fa6be527-b69b-41de-bbdc-532a1e7fe122@github.com>
References: <NMe-IE1hpqjx8hpUXBRULL1BXqUjM92QzPQLh0weCx4=.a4d5938d-89f5-4a48-ad25-b912367bf429@github.com>
 <pVXGQ1LY4daY6IAOZq4dSdOY4AN4r-6JxmWFr8TF0_g=.fa6be527-b69b-41de-bbdc-532a1e7fe122@github.com>
Message-ID: <fsnAS18ZdPPH0gHSmQ_QazFnLMjfny37hMMfOEYBdvs=.ddeb1335-1b44-43ff-8596-7f04fc95866f@github.com>

On Fri, 8 Nov 2024 22:03:04 GMT, hanklo6 <duke at openjdk.org> wrote:

>> Babylon Java Triton example translates Java source code with Java Triton API into code model by code reflection.
>>  
>> In this PR, we traverse the given code model and output Triton MLIR dialect in the generic form, and then inject generated MLIR dialect into the Intel Triton backend. We then utilize Intel Triton backend to compile the Triton MLIR dialect into a SPIR-V module. Use `Jextract` to create Java binding of Intel Level Zero runtime and launch the given kernel function with it on Intel GPUs.
>> 
>> ## Usage
>> Navigate to the `cr-example/triton` directory and execute `mvn clean test`. This will generate multiple MLIR files in the `result` directory ready to be processed by the Triton backend. 
>> 
>> Next, modify the `compiler.py` file within the `intel-xpu-triton-backend` project by applying the patch `git apply add-mlir-insertion.patch`. Then run the Triton backend by running `python3 translate.py`.
>> 
>> The Triton backend will generate SPIR-V files, which will be located under `~/.triton/cache/{hash_value}/{kernel_name}/{kernel_name}.spv`.
>> 
>> To create a binding for Level Zero, execute the below commands:
>> 
>> $JEXTRACT_DIR/bin/jextract --output src/gen/java -I /usr/include -t oneapi.levelzero level-zero/include/ze_api.h
>> $JAVA_HOME/bin/javac -cp target/classes -d target/classes src/gen/java/oneapi/levelzero/*.java
>> $JAVA_HOME/bin/jar cf levelzero.jar -C target/classes/ .
>> 
>> The will generate `levelzero.jar` in the current directory.
>> 
>> After getting JAR files for Level Zero and `JSON-java`, proceed to compile and run the launcher `LevelZero.java` with the following commands:
>> 
>> babylon/build/linux-x86_64-server-release/jdk/bin/javac -cp .:levelzero.jar:json-java.jar LevelZero.java
>> babylon/build/linux-x86_64-server-release/jdk/bin/java -ea -cp .:levelzero.jar:json-java.jar LevelZero
>> 
>> 
>> Ensure the hash values in`~/.triton/cache` match those used in the `LevelZero.java`.
>> 
>> ## Dependencies
>> - [intel-xpu-backend-for-triton](https://github.com/intel/intel-xpu-backend-for-triton)
>> - [intel-extension-for-pytorch](https://github.com/intel/intel-extension-for-pytorch)
>> - [Intel oneAPI base Toolkit](https://www.intel.com/content/www/us/en/developer/tools/oneapi/base-toolkit-download.html)
>> - [Jextract](https://github.com/openjdk/jextract)
>> - [Level Zero loader](https://github.com/oneapi-src/level-zero)
>> - [compute-runtime](https://github.com/intel/compute-runtime/releases)
>> - [JSON-java](https://github.com/stleary/JSON-java)
>
> hanklo6 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add the test for matrix multiplication with float16

I think this is good to go, just need to merge first and resolve conflicts before we integrate.

-------------

Marked as reviewed by psandoz (Lead).

PR Review: https://git.openjdk.org/babylon/pull/241#pullrequestreview-2493910678

From mcimadamore at openjdk.org  Wed Dec 11 16:51:27 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 11 Dec 2024 16:51:27 GMT
Subject: [code-reflection] Integrated: Revert change
In-Reply-To: <wJuUtpf6DhZmM-IDNUHtDmaH-7sDdpLfK_fen2LHVKc=.638db961-e92d-4538-ab7c-fdf1a7b40d3b@github.com>
References: <wJuUtpf6DhZmM-IDNUHtDmaH-7sDdpLfK_fen2LHVKc=.638db961-e92d-4538-ab7c-fdf1a7b40d3b@github.com>
Message-ID: <Hck_d9FAKAN_xR8DuEZj8KrWte7OHEk-jdwo97ZwtPw=.bd28c4e9-e34f-43ec-9635-b705464b0ff5@github.com>

On Tue, 10 Dec 2024 21:41:19 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Revert as we no longer need to explicitly copy.

Thanks!

-------------

PR Review: https://git.openjdk.org/babylon/pull/295#pullrequestreview-2496260421

From duke at openjdk.org  Thu Dec 12 18:23:14 2024
From: duke at openjdk.org (iotamudelta)
Date: Thu, 12 Dec 2024 18:23:14 GMT
Subject: [code-reflection] RFR: Integrate HIP backend to bldr infrastructure.
Message-ID: <FeTaN009eviFNSrX4weilMJnL0bcrwJzDVhSXn5F3eA=.972f1d8f-338f-479b-be76-7cc5d88422f1@github.com>

jextract fails in the presence of HIP on OpenCL/OpenGL - disable those for now if HIP is present.

While there, catch up to the reflection include change.

-------------

Commit messages:
 - Integrate HIP backend to bldr infrastructure.

Changes: https://git.openjdk.org/babylon/pull/296/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=296&range=00
  Stats: 18 lines in 6 files changed: 10 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/babylon/pull/296.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/296/head:pull/296

PR: https://git.openjdk.org/babylon/pull/296

From duke at openjdk.org  Thu Dec 12 23:44:41 2024
From: duke at openjdk.org (hanklo6)
Date: Thu, 12 Dec 2024 23:44:41 GMT
Subject: [code-reflection] RFR: Integrate Java Triton example with Intel
 Triton Backend [v5]
In-Reply-To: <NMe-IE1hpqjx8hpUXBRULL1BXqUjM92QzPQLh0weCx4=.a4d5938d-89f5-4a48-ad25-b912367bf429@github.com>
References: <NMe-IE1hpqjx8hpUXBRULL1BXqUjM92QzPQLh0weCx4=.a4d5938d-89f5-4a48-ad25-b912367bf429@github.com>
Message-ID: <12ffLwUtO08iHAmo_sNE3nFi7jHwHK-NQX2WZFb8bL8=.3da81c48-20e2-49f2-ae09-f965f9daa226@github.com>

> Babylon Java Triton example translates Java source code with Java Triton API into code model by code reflection.
>  
> In this PR, we traverse the given code model and output Triton MLIR dialect in the generic form, and then inject generated MLIR dialect into the Intel Triton backend. We then utilize Intel Triton backend to compile the Triton MLIR dialect into a SPIR-V module. Use `Jextract` to create Java binding of Intel Level Zero runtime and launch the given kernel function with it on Intel GPUs.
> 
> ## Usage
> Navigate to the `cr-example/triton` directory and execute `mvn clean test`. This will generate multiple MLIR files in the `result` directory ready to be processed by the Triton backend. 
> 
> Next, modify the `compiler.py` file within the `intel-xpu-triton-backend` project by applying the patch `git apply add-mlir-insertion.patch`. Then run the Triton backend by running `python3 translate.py`.
> 
> The Triton backend will generate SPIR-V files, which will be located under `~/.triton/cache/{hash_value}/{kernel_name}/{kernel_name}.spv`.
> 
> To create a binding for Level Zero, execute the below commands:
> 
> $JEXTRACT_DIR/bin/jextract --output src/gen/java -I /usr/include -t oneapi.levelzero level-zero/include/ze_api.h
> $JAVA_HOME/bin/javac -cp target/classes -d target/classes src/gen/java/oneapi/levelzero/*.java
> $JAVA_HOME/bin/jar cf levelzero.jar -C target/classes/ .
> 
> The will generate `levelzero.jar` in the current directory.
> 
> After getting JAR files for Level Zero and `JSON-java`, proceed to compile and run the launcher `LevelZero.java` with the following commands:
> 
> babylon/build/linux-x86_64-server-release/jdk/bin/javac -cp .:levelzero.jar:json-java.jar LevelZero.java
> babylon/build/linux-x86_64-server-release/jdk/bin/java -ea -cp .:levelzero.jar:json-java.jar LevelZero
> 
> 
> Ensure the hash values in`~/.triton/cache` match those used in the `LevelZero.java`.
> 
> ## Dependencies
> - [intel-xpu-backend-for-triton](https://github.com/intel/intel-xpu-backend-for-triton)
> - [intel-extension-for-pytorch](https://github.com/intel/intel-extension-for-pytorch)
> - [Intel oneAPI base Toolkit](https://www.intel.com/content/www/us/en/developer/tools/oneapi/base-toolkit-download.html)
> - [Jextract](https://github.com/openjdk/jextract)
> - [Level Zero loader](https://github.com/oneapi-src/level-zero)
> - [compute-runtime](https://github.com/intel/compute-runtime/releases)
> - [JSON-java](https://github.com/stleary/JSON-java)

hanklo6 has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Update import from reflect to incubator
 - Merge branch 'code-reflection' of https://git.openjdk.org/babylon into triton
 - Add the test for matrix multiplication with float16
 - Simplify zero initialization in dot method
 - Update MLIR output paths
 - Update attribute name
 - Add comments
 - Fix trailing and leading whitespaces
 - Use system home in the path
 - Add launcher code and translate code
 - ... and 7 more: https://git.openjdk.org/babylon/compare/79cd5cf3...c92a8adc

-------------

Changes: https://git.openjdk.org/babylon/pull/241/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=241&range=04
  Stats: 2497 lines in 14 files changed: 2345 ins; 4 del; 148 mod
  Patch: https://git.openjdk.org/babylon/pull/241.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/241/head:pull/241

PR: https://git.openjdk.org/babylon/pull/241

From duke at openjdk.org  Thu Dec 12 23:44:41 2024
From: duke at openjdk.org (hanklo6)
Date: Thu, 12 Dec 2024 23:44:41 GMT
Subject: [code-reflection] RFR: Integrate Java Triton example with Intel
 Triton Backend [v4]
In-Reply-To: <NtiTi99wDUFpgTocYASjAHeHzCwYNNDmkwWYf9HBRf4=.52c0d1b3-8975-4ae3-a91e-d04a7d1527a7@github.com>
References: <NMe-IE1hpqjx8hpUXBRULL1BXqUjM92QzPQLh0weCx4=.a4d5938d-89f5-4a48-ad25-b912367bf429@github.com>
 <pVXGQ1LY4daY6IAOZq4dSdOY4AN4r-6JxmWFr8TF0_g=.fa6be527-b69b-41de-bbdc-532a1e7fe122@github.com>
 <NtiTi99wDUFpgTocYASjAHeHzCwYNNDmkwWYf9HBRf4=.52c0d1b3-8975-4ae3-a91e-d04a7d1527a7@github.com>
Message-ID: <nT-06U1cXMz4PWT3Pr89MzjmtvMM1-5IiVT54D-M1CI=.7e565d23-74f2-4e96-a29f-0e7bb3c469b9@github.com>

On Fri, 6 Dec 2024 16:23:33 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> hanklo6 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add the test for matrix multiplication with float16
>
> Keep alive, need to give it another quick review.

@PaulSandoz Thank you for the review. I've merged the code.

-------------

PR Comment: https://git.openjdk.org/babylon/pull/241#issuecomment-2540225094

From psandoz at openjdk.org  Thu Dec 12 23:51:47 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 12 Dec 2024 23:51:47 GMT
Subject: [code-reflection] RFR: Integrate Java Triton example with Intel
 Triton Backend [v4]
In-Reply-To: <NtiTi99wDUFpgTocYASjAHeHzCwYNNDmkwWYf9HBRf4=.52c0d1b3-8975-4ae3-a91e-d04a7d1527a7@github.com>
References: <NMe-IE1hpqjx8hpUXBRULL1BXqUjM92QzPQLh0weCx4=.a4d5938d-89f5-4a48-ad25-b912367bf429@github.com>
 <pVXGQ1LY4daY6IAOZq4dSdOY4AN4r-6JxmWFr8TF0_g=.fa6be527-b69b-41de-bbdc-532a1e7fe122@github.com>
 <NtiTi99wDUFpgTocYASjAHeHzCwYNNDmkwWYf9HBRf4=.52c0d1b3-8975-4ae3-a91e-d04a7d1527a7@github.com>
Message-ID: <PePXcVNO3NQnA96KcvF6OMql4YgxPOAUK5YNNCtJTXc=.743e0379-bdac-44da-a81c-4a7bf7569fb5@github.com>

On Fri, 6 Dec 2024 16:23:33 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> hanklo6 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add the test for matrix multiplication with float16
>
> Keep alive, need to give it another quick review.

> @PaulSandoz Thank you for the review. I've merged the code.

Thanks. Type "/integrate" and then i can sponsor it.

-------------

PR Comment: https://git.openjdk.org/babylon/pull/241#issuecomment-2540233116

From duke at openjdk.org  Thu Dec 12 23:56:03 2024
From: duke at openjdk.org (duke)
Date: Thu, 12 Dec 2024 23:56:03 GMT
Subject: [code-reflection] RFR: Integrate Java Triton example with Intel
 Triton Backend [v5]
In-Reply-To: <12ffLwUtO08iHAmo_sNE3nFi7jHwHK-NQX2WZFb8bL8=.3da81c48-20e2-49f2-ae09-f965f9daa226@github.com>
References: <NMe-IE1hpqjx8hpUXBRULL1BXqUjM92QzPQLh0weCx4=.a4d5938d-89f5-4a48-ad25-b912367bf429@github.com>
 <12ffLwUtO08iHAmo_sNE3nFi7jHwHK-NQX2WZFb8bL8=.3da81c48-20e2-49f2-ae09-f965f9daa226@github.com>
Message-ID: <Zh4lcfVo6dFVdNlaMULw3Ra-Om6An-TRbHIsFEzlIig=.aa104a0f-f6f8-4447-a70b-d2bbe3407f84@github.com>

On Thu, 12 Dec 2024 23:44:41 GMT, hanklo6 <duke at openjdk.org> wrote:

>> Babylon Java Triton example translates Java source code with Java Triton API into code model by code reflection.
>>  
>> In this PR, we traverse the given code model and output Triton MLIR dialect in the generic form, and then inject generated MLIR dialect into the Intel Triton backend. We then utilize Intel Triton backend to compile the Triton MLIR dialect into a SPIR-V module. Use `Jextract` to create Java binding of Intel Level Zero runtime and launch the given kernel function with it on Intel GPUs.
>> 
>> ## Usage
>> Navigate to the `cr-example/triton` directory and execute `mvn clean test`. This will generate multiple MLIR files in the `result` directory ready to be processed by the Triton backend. 
>> 
>> Next, modify the `compiler.py` file within the `intel-xpu-triton-backend` project by applying the patch `git apply add-mlir-insertion.patch`. Then run the Triton backend by running `python3 translate.py`.
>> 
>> The Triton backend will generate SPIR-V files, which will be located under `~/.triton/cache/{hash_value}/{kernel_name}/{kernel_name}.spv`.
>> 
>> To create a binding for Level Zero, execute the below commands:
>> 
>> $JEXTRACT_DIR/bin/jextract --output src/gen/java -I /usr/include -t oneapi.levelzero level-zero/include/ze_api.h
>> $JAVA_HOME/bin/javac -cp target/classes -d target/classes src/gen/java/oneapi/levelzero/*.java
>> $JAVA_HOME/bin/jar cf levelzero.jar -C target/classes/ .
>> 
>> The will generate `levelzero.jar` in the current directory.
>> 
>> After getting JAR files for Level Zero and `JSON-java`, proceed to compile and run the launcher `LevelZero.java` with the following commands:
>> 
>> babylon/build/linux-x86_64-server-release/jdk/bin/javac -cp .:levelzero.jar:json-java.jar LevelZero.java
>> babylon/build/linux-x86_64-server-release/jdk/bin/java -ea -cp .:levelzero.jar:json-java.jar LevelZero
>> 
>> 
>> Ensure the hash values in`~/.triton/cache` match those used in the `LevelZero.java`.
>> 
>> ## Dependencies
>> - [intel-xpu-backend-for-triton](https://github.com/intel/intel-xpu-backend-for-triton)
>> - [intel-extension-for-pytorch](https://github.com/intel/intel-extension-for-pytorch)
>> - [Intel oneAPI base Toolkit](https://www.intel.com/content/www/us/en/developer/tools/oneapi/base-toolkit-download.html)
>> - [Jextract](https://github.com/openjdk/jextract)
>> - [Level Zero loader](https://github.com/oneapi-src/level-zero)
>> - [compute-runtime](https://github.com/intel/compute-runtime/releases)
>> - [JSON-java](https://github.com/stleary/JSON-java)
>
> hanklo6 has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Update import from reflect to incubator
>  - Merge branch 'code-reflection' of https://git.openjdk.org/babylon into triton
>  - Add the test for matrix multiplication with float16
>  - Simplify zero initialization in dot method
>  - Update MLIR output paths
>  - Update attribute name
>  - Add comments
>  - Fix trailing and leading whitespaces
>  - Use system home in the path
>  - Add launcher code and translate code
>  - ... and 7 more: https://git.openjdk.org/babylon/compare/79cd5cf3...c92a8adc

@hanklo6 
Your change (at version c92a8adc23f4ae264043ec4278eb4a5186355d63) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/babylon/pull/241#issuecomment-2540237690

From psandoz at openjdk.org  Thu Dec 12 23:59:19 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 12 Dec 2024 23:59:19 GMT
Subject: git: openjdk/babylon: code-reflection: Integrate Java Triton example
 with Intel Triton Backend
Message-ID: <7387bbf0-17a5-45db-87fd-3429c860e7e5@openjdk.org>

Changeset: c0c70a43
Branch: code-reflection
Author:    hanklo6 <hank.lo at intel.com>
Committer: Paul Sandoz <psandoz at openjdk.org>
Date:      2024-12-12 23:57:42 +0000
URL:       https://git.openjdk.org/babylon/commit/c0c70a431bd35542bbef8ba94b0c419a4371f441

Integrate Java Triton example with Intel Triton Backend

Reviewed-by: psandoz

+ cr-examples/triton/add-mlir-insertion.patch
! cr-examples/triton/pom.xml
+ cr-examples/triton/spirv/LevelZero.java
+ cr-examples/triton/spirv/translate.py
! cr-examples/triton/src/main/java/oracle/code/triton/ArithMathOps.java
+ cr-examples/triton/src/main/java/oracle/code/triton/MLIRGenerator.java
! cr-examples/triton/src/main/java/oracle/code/triton/Triton.java
! cr-examples/triton/src/main/java/oracle/code/triton/TritonOps.java
! cr-examples/triton/src/main/java/oracle/code/triton/TritonTransformer.java
! cr-examples/triton/src/test/java/oracle/code/triton/TestAddKernel.java
! cr-examples/triton/src/test/java/oracle/code/triton/TestMatrix.java
+ cr-examples/triton/src/test/java/oracle/code/triton/TestMatrixFp16.java
! cr-examples/triton/src/test/java/oracle/code/triton/TestSoftMax.java
! cr-examples/triton/src/test/java/oracle/code/triton/TritonTestExtension.java


From duke at openjdk.org  Fri Dec 13 00:01:09 2024
From: duke at openjdk.org (hanklo6)
Date: Fri, 13 Dec 2024 00:01:09 GMT
Subject: [code-reflection] Integrated: Integrate Java Triton example with Intel
 Triton Backend
In-Reply-To: <NMe-IE1hpqjx8hpUXBRULL1BXqUjM92QzPQLh0weCx4=.a4d5938d-89f5-4a48-ad25-b912367bf429@github.com>
References: <NMe-IE1hpqjx8hpUXBRULL1BXqUjM92QzPQLh0weCx4=.a4d5938d-89f5-4a48-ad25-b912367bf429@github.com>
Message-ID: <V6oPbplXW1LEBWCW-PI1AzG043hxj5RLmAlujdn8AuY=.d827e618-55ef-4a65-94db-ac26ff6b674b@github.com>

On Wed, 25 Sep 2024 15:32:53 GMT, hanklo6 <duke at openjdk.org> wrote:

> Babylon Java Triton example translates Java source code with Java Triton API into code model by code reflection.
>  
> In this PR, we traverse the given code model and output Triton MLIR dialect in the generic form, and then inject generated MLIR dialect into the Intel Triton backend. We then utilize Intel Triton backend to compile the Triton MLIR dialect into a SPIR-V module. Use `Jextract` to create Java binding of Intel Level Zero runtime and launch the given kernel function with it on Intel GPUs.
> 
> ## Usage
> Navigate to the `cr-example/triton` directory and execute `mvn clean test`. This will generate multiple MLIR files in the `result` directory ready to be processed by the Triton backend. 
> 
> Next, modify the `compiler.py` file within the `intel-xpu-triton-backend` project by applying the patch `git apply add-mlir-insertion.patch`. Then run the Triton backend by running `python3 translate.py`.
> 
> The Triton backend will generate SPIR-V files, which will be located under `~/.triton/cache/{hash_value}/{kernel_name}/{kernel_name}.spv`.
> 
> To create a binding for Level Zero, execute the below commands:
> 
> $JEXTRACT_DIR/bin/jextract --output src/gen/java -I /usr/include -t oneapi.levelzero level-zero/include/ze_api.h
> $JAVA_HOME/bin/javac -cp target/classes -d target/classes src/gen/java/oneapi/levelzero/*.java
> $JAVA_HOME/bin/jar cf levelzero.jar -C target/classes/ .
> 
> The will generate `levelzero.jar` in the current directory.
> 
> After getting JAR files for Level Zero and `JSON-java`, proceed to compile and run the launcher `LevelZero.java` with the following commands:
> 
> babylon/build/linux-x86_64-server-release/jdk/bin/javac -cp .:levelzero.jar:json-java.jar LevelZero.java
> babylon/build/linux-x86_64-server-release/jdk/bin/java -ea -cp .:levelzero.jar:json-java.jar LevelZero
> 
> 
> Ensure the hash values in`~/.triton/cache` match those used in the `LevelZero.java`.
> 
> ## Dependencies
> - [intel-xpu-backend-for-triton](https://github.com/intel/intel-xpu-backend-for-triton)
> - [intel-extension-for-pytorch](https://github.com/intel/intel-extension-for-pytorch)
> - [Intel oneAPI base Toolkit](https://www.intel.com/content/www/us/en/developer/tools/oneapi/base-toolkit-download.html)
> - [Jextract](https://github.com/openjdk/jextract)
> - [Level Zero loader](https://github.com/oneapi-src/level-zero)
> - [compute-runtime](https://github.com/intel/compute-runtime/releases)
> - [JSON-java](https://github.com/stleary/JSON-java)

This pull request has now been integrated.

Changeset: c0c70a43
Author:    hanklo6 <hank.lo at intel.com>
Committer: Paul Sandoz <psandoz at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/c0c70a431bd35542bbef8ba94b0c419a4371f441
Stats:     2497 lines in 14 files changed: 2345 ins; 4 del; 148 mod

Integrate Java Triton example with Intel Triton Backend

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.org/babylon/pull/241

From gfrost at openjdk.org  Mon Dec 16 11:23:37 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Mon, 16 Dec 2024 11:23:37 GMT
Subject: git: openjdk/babylon: code-reflection: Hat bld and dir changes in prep
 for separating native ffi and jextracted backends
Message-ID: <fed652c2-282a-4a61-aa32-9bb3d2c72aa4@openjdk.org>

Changeset: 490332b1
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2024-12-16 11:22:00 +0000
URL:       https://git.openjdk.org/babylon/commit/490332b12e479d8a0c164cb32dab1def982d8fce

Hat bld and dir changes in prep for separating native ffi and jextracted backends

- hat/backends/cuda/pom.xml
- hat/backends/cuda/src/main/resources/META-INF/services/hat.backend.Backend
= hat/backends/ffi/CMakeLists.txt
= hat/backends/ffi/cuda/.gitignore
= hat/backends/ffi/cuda/CMakeLists.txt
= hat/backends/ffi/cuda/cpp/cuda_backend.cpp
= hat/backends/ffi/cuda/cpp/info.cpp
= hat/backends/ffi/cuda/include/cuda_backend.h
+ hat/backends/ffi/cuda/pom.xml
= hat/backends/ffi/cuda/src/main/java/hat/backend/ffi/CudaBackend.java
= hat/backends/ffi/cuda/src/main/java/hat/backend/ffi/CudaDeviceInfo.java
= hat/backends/ffi/cuda/src/main/java/hat/backend/ffi/CudaHatKernelBuilder.java
+ hat/backends/ffi/cuda/src/main/resources/META-INF/services/hat.backend.Backend
= hat/backends/ffi/hip/CMakeLists.txt
= hat/backends/ffi/hip/cpp/hip_backend.cpp
= hat/backends/ffi/hip/cpp/info.cpp
= hat/backends/ffi/hip/include/hip_backend.h
+ hat/backends/ffi/hip/pom.xml
= hat/backends/ffi/hip/src/main/java/hat/backend/HIPBackend.java
= hat/backends/ffi/hip/src/main/java/hat/backend/HIPDeviceInfo.java
= hat/backends/ffi/hip/src/main/java/hat/backend/HIPHatKernelBuilder.java
= hat/backends/ffi/hip/src/main/resources/META-INF/services/hat.backend.Backend
= hat/backends/ffi/mock/.gitignore
= hat/backends/ffi/mock/CMakeLists.txt
= hat/backends/ffi/mock/cpp/info.cpp
= hat/backends/ffi/mock/cpp/mock_backend.cpp
+ hat/backends/ffi/mock/pom.xml
= hat/backends/ffi/mock/src/main/java/hat/backend/ffi/MockBackend.java
= hat/backends/ffi/mock/src/main/java/hat/backend/ffi/MockDeviceInfo.java
= hat/backends/ffi/mock/src/main/java/hat/backend/ffi/TestIt.java
+ hat/backends/ffi/mock/src/main/resources/META-INF/services/hat.backend.Backend
= hat/backends/ffi/opencl/.gitignore
= hat/backends/ffi/opencl/CMakeLists.txt
= hat/backends/ffi/opencl/cpp/info.cpp
= hat/backends/ffi/opencl/cpp/opencl_backend.cpp
= hat/backends/ffi/opencl/include/opencl_backend.h
+ hat/backends/ffi/opencl/pom.xml
= hat/backends/ffi/opencl/src/main/java/hat/backend/ffi/OpenCLBackend.java
= hat/backends/ffi/opencl/src/main/java/hat/backend/ffi/OpenCLDeviceInfo.java
= hat/backends/ffi/opencl/src/main/java/hat/backend/ffi/OpenCLHatKernelBuilder.java
+ hat/backends/ffi/opencl/src/main/resources/META-INF/services/hat.backend.Backend
= hat/backends/ffi/pom.xml
= hat/backends/ffi/ptx/.gitignore
= hat/backends/ffi/ptx/CMakeLists.txt
= hat/backends/ffi/ptx/cpp/info.cpp
= hat/backends/ffi/ptx/cpp/ptx_backend.cpp
= hat/backends/ffi/ptx/include/ptx_backend.h
+ hat/backends/ffi/ptx/pom.xml
= hat/backends/ffi/ptx/src/main/java/hat/backend/ffi/PTXBackend.java
= hat/backends/ffi/ptx/src/main/java/hat/backend/ffi/PTXCodeBuilder.java
= hat/backends/ffi/ptx/src/main/java/hat/backend/ffi/PTXDeviceInfo.java
= hat/backends/ffi/ptx/src/main/java/hat/backend/ffi/PTXPtrOp.java
= hat/backends/ffi/ptx/src/main/java/hat/backend/ffi/PTXRegister.java
= hat/backends/ffi/ptx/src/main/java/hat/backend/ffi/TestIt.java
+ hat/backends/ffi/ptx/src/main/resources/META-INF/services/hat.backend.Backend
= hat/backends/ffi/shared/cpp/schema.cpp
= hat/backends/ffi/shared/cpp/schemadump.cpp
= hat/backends/ffi/shared/cpp/shared.cpp
= hat/backends/ffi/shared/include/cursor.h
= hat/backends/ffi/shared/include/schema.h
= hat/backends/ffi/shared/include/shared.h
+ hat/backends/ffi/shared/src/main/resources/META-INF/services/hat.backend.Backend
= hat/backends/ffi/spirv/CMakeLists.txt
= hat/backends/ffi/spirv/README.md
= hat/backends/ffi/spirv/cpp/info.cpp
= hat/backends/ffi/spirv/cpp/spirv_backend.cpp
+ hat/backends/ffi/spirv/pom.xml
= hat/backends/ffi/spirv/scripts/build-beehive-spirv-toolkit.sh
= hat/backends/ffi/spirv/scripts/build-level-zero.sh
= hat/backends/ffi/spirv/scripts/generate-level-zero-binding.sh
= hat/backends/ffi/spirv/src/main/java/hat/backend/SpirvBackend.java
= hat/backends/ffi/spirv/src/main/java/hat/backend/SpirvDeviceInfo.java
= hat/backends/ffi/spirv/src/main/java/hat/backend/TestIt.java
= hat/backends/ffi/spirv/src/main/java/intel/code/spirv/LevelZero.java
= hat/backends/ffi/spirv/src/main/java/intel/code/spirv/PointerType.java
= hat/backends/ffi/spirv/src/main/java/intel/code/spirv/SpirvModuleGenerator.java
= hat/backends/ffi/spirv/src/main/java/intel/code/spirv/SpirvOp.java
= hat/backends/ffi/spirv/src/main/java/intel/code/spirv/SpirvType.java
= hat/backends/ffi/spirv/src/main/java/intel/code/spirv/StorageType.java
= hat/backends/ffi/spirv/src/main/java/intel/code/spirv/TranslateToSpirvModel.java
= hat/backends/ffi/spirv/src/main/java/intel/code/spirv/UsmArena.java
+ hat/backends/ffi/spirv/src/main/resources/META-INF/services/hat.backend.Backend
- hat/backends/hip/pom.xml
+ hat/backends/java/mt/pom.xml
+ hat/backends/java/mt/src/main/resources/META-INF/services/hat.backend.Backend
+ hat/backends/java/pom.xml
+ hat/backends/java/seq/pom.xml
+ hat/backends/java/seq/src/main/resources/META-INF/services/hat.backend.Backend
+ hat/backends/jextracted/opencl/src/main/java/hat/backend/jextracted/CLWrap.java
+ hat/backends/jextracted/opencl/src/main/java/hat/backend/jextracted/OpenCLBackend.java
= hat/backends/jextracted/opencl/src/main/java/hat/backend/jextracted/OpenCLHatKernelBuilder.java
+ hat/backends/jextracted/opencl/src/main/resources/META-INF/services/hat.backend.Backend
= hat/backends/jextracted/shared/src/main/resources/META-INF/services/hat.backend.Backend
- hat/backends/mock/pom.xml
- hat/backends/mock/src/main/resources/META-INF/services/hat.backend.Backend
- hat/backends/opencl/pom.xml
- hat/backends/opencl/src/main/resources/META-INF/services/hat.backend.Backend
! hat/backends/pom.xml
- hat/backends/ptx/pom.xml
- hat/backends/ptx/src/main/resources/META-INF/services/hat.backend.Backend
- hat/backends/shared/src/main/java/unused/Unused.java
- hat/backends/shared/src/main/resources/META-INF/services/hat.backend.Backend
- hat/backends/spirv/pom.xml
- hat/backends/spirv/src/main/resources/META-INF/services/hat.backend.Backend
! hat/bld
! hat/bldr/Bldr.java
- hat/bldr/CMakeProbe.java
- hat/bldr/Capabilities.java
- hat/bldr/MavenStyleRepository.java
- hat/bldr/Regex.java
- hat/bldr/XMLNode.java
+ hat/bldr/scriptformat.xml
! hat/clean
! hat/docs/hat-01-01-project-layout.md
! hat/docs/hat-01-03-building-hat-with-maven.md
! hat/docs/hat-01-03-building-hat.md
! hat/examples/blackscholes/pom.xml
! hat/examples/heal/pom.xml
! hat/examples/life/pom.xml
! hat/examples/mandel/pom.xml
! hat/examples/nbody/src/main/java/nbody/CLWrap.java
! hat/examples/nbody/src/main/java/nbody/Main.java
! hat/examples/pom.xml
! hat/examples/squares/pom.xml
! hat/examples/violajones/pom.xml
! hat/examples/violajones/src/main/java/violajones/attic/ViolaJones.java
! hat/extractions/opencl/pom.xml
! hat/extractions/opengl/pom.xml
! hat/extractions/pom.xml
! hat/hat/pom.xml
! hat/hat/src/main/java/hat/backend/Backend.java
- hat/hat/src/main/java/hat/backend/C99NativeBackend.java
- hat/hat/src/main/java/hat/backend/NativeLib.java
+ hat/hat/src/main/java/hat/backend/ffi/C99FFIBackend.java
= hat/hat/src/main/java/hat/backend/ffi/FFIBackend.java
= hat/hat/src/main/java/hat/backend/ffi/FFIBackendDriver.java
+ hat/hat/src/main/java/hat/backend/ffi/FFILib.java
= hat/hat/src/main/java/hat/backend/java/JavaBackend.java
= hat/hat/src/main/java/hat/backend/java/JavaMultiThreadedBackend.java
= hat/hat/src/main/java/hat/backend/java/JavaSequentialBackend.java
= hat/hat/src/main/java/hat/backend/java/WorkStealer.java
+ hat/hat/src/main/java/hat/backend/jextracted/C99JExtractedBackend.java
= hat/hat/src/main/java/hat/backend/jextracted/JExtractedBackend.java
= hat/hat/src/main/java/hat/backend/jextracted/JExtractedBackendDriver.java
! hat/hat/src/main/test/hat/SquaresTest.java
! hat/hatrun
! hat/hatrun.bash
! hat/intellij/.idea/modules.xml
- hat/intellij/backend_cuda.iml
+ hat/intellij/backend_ffi_cuda.iml
+ hat/intellij/backend_ffi_mock.iml
+ hat/intellij/backend_ffi_opencl.iml
+ hat/intellij/backend_ffi_ptx.iml
+ hat/intellij/backend_ffi_shared.iml
+ hat/intellij/backend_ffi_spirv.iml
+ hat/intellij/backend_java_mt.iml
+ hat/intellij/backend_java_seq.iml
+ hat/intellij/backend_jextracted_opencl.iml
+ hat/intellij/backend_jextracted_shared.iml
- hat/intellij/backend_mock.iml
- hat/intellij/backend_opencl.iml
- hat/intellij/backend_ptx.iml
- hat/intellij/backend_shared.iml
- hat/intellij/backend_spirv.iml
! hat/intellij/nbody.iml
! hat/mkpoms
! hat/pom.xml
! hat/sanity


From gfrost at openjdk.org  Mon Dec 16 11:27:30 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Mon, 16 Dec 2024 11:27:30 GMT
Subject: [code-reflection] Integrated: Hat bld and dir changes in prep for
 separating native ffi and jextracted backends
Message-ID: <O_gF42lAtqrT221EKOwuGaRGmS6lgiQU0RDjq0wgJLQ=.4b2813ab-42c4-451f-b0f2-b544fa6c3633@github.com>

This looks like a huge change, but is mostly moving backend files around to allow us to have ffi backends (needing cmake to compile c++ source), jextracted backends (which rely on jextract to allow us to skip cmake) and pure java backends (sq and mt)

So under backends we now have an extra dir

backends
    +-- ffi
    |         +-- opencl
    |         +-- cuda         
    +-- jextracted
    |         +-- TBA
    +--java
    |       +-- seq
    |      +-- mt

The various project java srcs also have the appropriate packege name (say hat.backends.ffi.opencl) to avoid collisions if we were to ever consider including both in the path. 
 
This does effect how we run examples.  We need to include the 'type' of backend with hatrun, so 'ffi-opencl' instead of previous 'opencl'

java @ bldr/hatrun ffi-opencl heal

-------------

Commit messages:
 - whitespacery
 - updated docs and sanity script
 - Started work on jextracted opencl backend.  Cleaned up CLWrap.
 - prep for creating jextracted opencl backend
 - sync scripts with upstream
 - Swapped native for ffi so we can use package name
 - maven pomery
 - Some minor bld changes to reflect backend separation (java/native/jextracted)
 - Exposed java-mt and java-seq iml files
 - Moved 'native' backends to backends/native
 - ... and 2 more: https://git.openjdk.org/babylon/compare/2d6b5763...ae3e4ae2

Changes: https://git.openjdk.org/babylon/pull/297/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=297&range=00
  Stats: 8413 lines in 168 files changed: 4572 ins; 3139 del; 702 mod
  Patch: https://git.openjdk.org/babylon/pull/297.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/297/head:pull/297

PR: https://git.openjdk.org/babylon/pull/297

From gfrost at openjdk.org  Mon Dec 16 11:27:31 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Mon, 16 Dec 2024 11:27:31 GMT
Subject: [code-reflection] Integrated: Hat bld and dir changes in prep for
 separating native ffi and jextracted backends
In-Reply-To: <O_gF42lAtqrT221EKOwuGaRGmS6lgiQU0RDjq0wgJLQ=.4b2813ab-42c4-451f-b0f2-b544fa6c3633@github.com>
References: <O_gF42lAtqrT221EKOwuGaRGmS6lgiQU0RDjq0wgJLQ=.4b2813ab-42c4-451f-b0f2-b544fa6c3633@github.com>
Message-ID: <YueFmgORj2kZ9jWQHrEyMceaGpKC1JOpc2BR6nYk9As=.9a82014c-dcd8-4922-9b66-25661ef84d44@github.com>

On Mon, 16 Dec 2024 11:15:53 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> This looks like a huge change, but is mostly moving backend files around to allow us to have ffi backends (needing cmake to compile c++ source), jextracted backends (which rely on jextract to allow us to skip cmake) and pure java backends (sq and mt)
> 
> So under backends we now have an extra dir
> 
> backends
>     +-- ffi
>     |         +-- opencl
>     |         +-- cuda         
>     +-- jextracted
>     |         +-- TBA
>     +--java
>     |       +-- seq
>     |      +-- mt
> 
> The various project java srcs also have the appropriate packege name (say hat.backends.ffi.opencl) to avoid collisions if we were to ever consider including both in the path. 
>  
> This does effect how we run examples.  We need to include the 'type' of backend with hatrun, so 'ffi-opencl' instead of previous 'opencl'
> 
> java @ bldr/hatrun ffi-opencl heal

This pull request has now been integrated.

Changeset: 490332b1
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/490332b12e479d8a0c164cb32dab1def982d8fce
Stats:     8413 lines in 168 files changed: 4572 ins; 3139 del; 702 mod

Hat bld and dir changes in prep for separating native ffi and jextracted backends

-------------

PR: https://git.openjdk.org/babylon/pull/297

From duke at openjdk.org  Mon Dec 16 22:24:27 2024
From: duke at openjdk.org (hanklo6)
Date: Mon, 16 Dec 2024 22:24:27 GMT
Subject: [code-reflection] RFR: Support for Generalized Buffer Type in Hat
 SPIR-V Backend
Message-ID: <iciWNN7LHxLpsttDq-x-pqDfWHCPA4Xw0_qvz5DnY6w=.5c8b1360-e5d9-4b75-8093-c943b1518c06@github.com>

This PR introduces support for generalized buffer by creating SPIRV type structure and arrays in the generated module. Most of the implementation references the OpenCL Hat builder. The SPIR-V module assumes the same memory layout as the java buffer object, provided there is not additional customized padding between fields. Also, generated dependent functions from callgraph instead of using code model to resolve the issue where private functions can't be accessed.

The blackscholes, mandel, and violajones examples now run successfully. However, the violajones example still gets wrong value when accessing `threshold` from `stage` inside `isAFaceStage` function, so I currently update the condition to `sumOfThisStage > threshold`.

For machines that don't have `float64` capability, enable `FP64` emulation by setting the environment variable: `OverrideDefaultFP64Settings=1` and `IGC_EnableDPEmulation=1` before running. For more details: https://github.com/intel/compute-runtime/blob/master/opencl/doc/FAQ.md#feature-double-precision-emulation-fp64

-------------

Commit messages:
 - Remove whitespace
 - Support iface buffer
 - Print log during building module

Changes: https://git.openjdk.org/babylon/pull/298/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=298&range=00
  Stats: 518 lines in 5 files changed: 462 ins; 16 del; 40 mod
  Patch: https://git.openjdk.org/babylon/pull/298.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/298/head:pull/298

PR: https://git.openjdk.org/babylon/pull/298

From mabbay at openjdk.org  Thu Dec 19 02:40:28 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Thu, 19 Dec 2024 02:40:28 GMT
Subject: [code-reflection] RFR: Replace opField with opMethod for identified
 methods
Message-ID: <4y0CgR837WbBAokzbLNUf6l5KqJrXDKuwoOuoFtZA-I=.043e5b30-17fa-4af5-bcbb-ed4c3a7cceb9@github.com>

In this PR, instead of creating a field that will holds the textual representation of an identified method, we create a method (let's call it opMethod) that will returns the op of that method.

-------------

Commit messages:
 - Replace opField with opMethod for identified methods

Changes: https://git.openjdk.org/babylon/pull/299/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=299&range=00
  Stats: 65 lines in 5 files changed: 34 ins; 23 del; 8 mod
  Patch: https://git.openjdk.org/babylon/pull/299.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/299/head:pull/299

PR: https://git.openjdk.org/babylon/pull/299

From mabbay at openjdk.org  Thu Dec 19 02:59:16 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Thu, 19 Dec 2024 02:59:16 GMT
Subject: [code-reflection] RFR: Fix typos
Message-ID: <vk-kyvgKWDZea_SGLpHOzjVNJJ6tEHn3kbidtcpBBYc=.d4304926-270d-4b64-9325-3410a3e8145b@github.com>

This PR fixes typos introduced by #272.

-------------

Commit messages:
 - Fix typos

Changes: https://git.openjdk.org/babylon/pull/300/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=300&range=00
  Stats: 19 lines in 3 files changed: 10 ins; 6 del; 3 mod
  Patch: https://git.openjdk.org/babylon/pull/300.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/300/head:pull/300

PR: https://git.openjdk.org/babylon/pull/300

From mcimadamore at openjdk.org  Thu Dec 19 13:42:57 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 19 Dec 2024 13:42:57 GMT
Subject: [code-reflection] RFR: Replace opField with opMethod for
 identified methods
In-Reply-To: <4y0CgR837WbBAokzbLNUf6l5KqJrXDKuwoOuoFtZA-I=.043e5b30-17fa-4af5-bcbb-ed4c3a7cceb9@github.com>
References: <4y0CgR837WbBAokzbLNUf6l5KqJrXDKuwoOuoFtZA-I=.043e5b30-17fa-4af5-bcbb-ed4c3a7cceb9@github.com>
Message-ID: <TKWGbtvkIAqlWWEh3IdffaH1wf-dC1--2N5Nc7nvLnA=.26a65684-5699-4a07-b24a-32f99f91ecac@github.com>

On Thu, 19 Dec 2024 02:34:19 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> In this PR, instead of creating a field that will holds the textual representation of an identified method, we create a method (let's call it opMethod) that will returns the op of that method.

After this, we need another PR to fix lambda metafactory for `Quotable`. In that case we also pass a reference to a _field_ containing the op text to the `LambdaMetafactory` class. If we switch from field to methods, we should do so uniformly.

src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/ReflectMethods.java line 415:

> 413: 
> 414:         var opVarInit = make.App(make.Ident(crSyms.opParserFromString), com.sun.tools.javac.util.List.of(make.Literal(op.toText())));
> 415:         var opVar = make.VarDef(new VarSymbol(0, names.fromString("op"), crSyms.opType, ms), opVarInit);

I believe you can skip the intermediate var? E.g. just cast the result of calling the op parser method?

-------------

PR Review: https://git.openjdk.org/babylon/pull/299#pullrequestreview-2514732789
PR Review Comment: https://git.openjdk.org/babylon/pull/299#discussion_r1892122033

From mabbay at openjdk.org  Thu Dec 19 17:12:09 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Thu, 19 Dec 2024 17:12:09 GMT
Subject: git: openjdk/babylon: code-reflection: Fix typos
Message-ID: <c8adcd15-3d51-48cd-b9a7-163ff8bfe5ac@openjdk.org>

Changeset: da874e85
Branch: code-reflection
Author:    Mourad Abbay <mabbay at openjdk.org>
Date:      2024-12-19 17:10:49 +0000
URL:       https://git.openjdk.org/babylon/commit/da874e855a8e28d3327d13b42ce529a8c662d464

Fix typos

Reviewed-by: psandoz

! src/jdk.incubator.code/share/classes/jdk/incubator/code/op/CoreOp.java
! test/jdk/java/lang/reflect/code/TestInvokeOp.java
! test/jdk/java/lang/reflect/code/bytecode/TestVarArg.java


From mabbay at openjdk.org  Thu Dec 19 17:13:24 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Thu, 19 Dec 2024 17:13:24 GMT
Subject: [code-reflection] RFR: Fix typos [v2]
In-Reply-To: <vk-kyvgKWDZea_SGLpHOzjVNJJ6tEHn3kbidtcpBBYc=.d4304926-270d-4b64-9325-3410a3e8145b@github.com>
References: <vk-kyvgKWDZea_SGLpHOzjVNJJ6tEHn3kbidtcpBBYc=.d4304926-270d-4b64-9325-3410a3e8145b@github.com>
Message-ID: <VjjlrLyZzQYEppNkfnNPit_48Y9jiC6uCjF5PGEY0-w=.8785648d-4e05-4d6f-82c1-2d95c2974e2a@github.com>

> This PR fixes typos introduced by #272.

Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:

  Update src/jdk.incubator.code/share/classes/jdk/incubator/code/op/CoreOp.java
  
  Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>

-------------

Changes:
  - all: https://git.openjdk.org/babylon/pull/300/files
  - new: https://git.openjdk.org/babylon/pull/300/files/b5ce1ebb..a56fd41b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=300&range=01
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=300&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/babylon/pull/300.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/300/head:pull/300

PR: https://git.openjdk.org/babylon/pull/300

From psandoz at openjdk.org  Thu Dec 19 17:13:24 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 19 Dec 2024 17:13:24 GMT
Subject: [code-reflection] RFR: Fix typos [v2]
In-Reply-To: <VjjlrLyZzQYEppNkfnNPit_48Y9jiC6uCjF5PGEY0-w=.8785648d-4e05-4d6f-82c1-2d95c2974e2a@github.com>
References: <vk-kyvgKWDZea_SGLpHOzjVNJJ6tEHn3kbidtcpBBYc=.d4304926-270d-4b64-9325-3410a3e8145b@github.com>
 <VjjlrLyZzQYEppNkfnNPit_48Y9jiC6uCjF5PGEY0-w=.8785648d-4e05-4d6f-82c1-2d95c2974e2a@github.com>
Message-ID: <zANrZ8X-6YdEb4Yb51qp5yaLnJl0aaWGFdzV7pFA2pc=.f99e1a5b-cc4e-48a2-9418-9def723e902d@github.com>

On Thu, 19 Dec 2024 17:11:07 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> This PR fixes typos introduced by #272.
>
> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/jdk.incubator.code/share/classes/jdk/incubator/code/op/CoreOp.java
>   
>   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>

Marked as reviewed by psandoz (Lead).

src/jdk.incubator.code/share/classes/jdk/incubator/code/op/CoreOp.java line 1560:

> 1558: 
> 1559:         public List<Value> argOperands() {
> 1560:             if (!isVarArgs){

Suggestion:

            if (!isVarArgs) {

-------------

PR Review: https://git.openjdk.org/babylon/pull/300#pullrequestreview-2515624362
PR Review Comment: https://git.openjdk.org/babylon/pull/300#discussion_r1892768717

From mabbay at openjdk.org  Thu Dec 19 17:13:25 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Thu, 19 Dec 2024 17:13:25 GMT
Subject: [code-reflection] Integrated: Fix typos
In-Reply-To: <vk-kyvgKWDZea_SGLpHOzjVNJJ6tEHn3kbidtcpBBYc=.d4304926-270d-4b64-9325-3410a3e8145b@github.com>
References: <vk-kyvgKWDZea_SGLpHOzjVNJJ6tEHn3kbidtcpBBYc=.d4304926-270d-4b64-9325-3410a3e8145b@github.com>
Message-ID: <rlnxuo5IRx8brzFgMpiRLAgldCG-b1EtC-ZLhIO9aws=.e02ced7b-8373-40c9-9a7d-544c9d208707@github.com>

On Thu, 19 Dec 2024 02:54:28 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> This PR fixes typos introduced by #272.

This pull request has now been integrated.

Changeset: da874e85
Author:    Mourad Abbay <mabbay at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/da874e855a8e28d3327d13b42ce529a8c662d464
Stats:     19 lines in 3 files changed: 10 ins; 6 del; 3 mod

Fix typos

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.org/babylon/pull/300

From mabbay at openjdk.org  Thu Dec 19 18:25:26 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Thu, 19 Dec 2024 18:25:26 GMT
Subject: [code-reflection] RFR: Replace opField with opMethod for
 identified methods [v2]
In-Reply-To: <4y0CgR837WbBAokzbLNUf6l5KqJrXDKuwoOuoFtZA-I=.043e5b30-17fa-4af5-bcbb-ed4c3a7cceb9@github.com>
References: <4y0CgR837WbBAokzbLNUf6l5KqJrXDKuwoOuoFtZA-I=.043e5b30-17fa-4af5-bcbb-ed4c3a7cceb9@github.com>
Message-ID: <uBSiw7n25nXunSXoGNOmveaXU3RJtsGXrQdMZXdNpAY=.0a3d4ce1-8967-469a-9eec-2636cb95dcb6@github.com>

> In this PR, instead of creating a field that will holds the textual representation of an identified method, we create a method (let's call it opMethod) that will returns the op of that method.

Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions

-------------

Changes:
  - all: https://git.openjdk.org/babylon/pull/299/files
  - new: https://git.openjdk.org/babylon/pull/299/files/93581b2a..96e02596

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=299&range=01
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=299&range=00-01

  Stats: 41 lines in 5 files changed: 11 ins; 20 del; 10 mod
  Patch: https://git.openjdk.org/babylon/pull/299.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/299/head:pull/299

PR: https://git.openjdk.org/babylon/pull/299

From mabbay at openjdk.org  Thu Dec 19 18:36:28 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Thu, 19 Dec 2024 18:36:28 GMT
Subject: [code-reflection] RFR: Replace opField with opMethod for
 identified methods [v3]
In-Reply-To: <4y0CgR837WbBAokzbLNUf6l5KqJrXDKuwoOuoFtZA-I=.043e5b30-17fa-4af5-bcbb-ed4c3a7cceb9@github.com>
References: <4y0CgR837WbBAokzbLNUf6l5KqJrXDKuwoOuoFtZA-I=.043e5b30-17fa-4af5-bcbb-ed4c3a7cceb9@github.com>
Message-ID: <ejugQExWGN6N0xIWz0hZIi7ikiIK4YWbif2l9UFYDEk=.b9573a78-f177-4c4c-9eb6-85497ca1865d@github.com>

> In this PR, instead of creating a field that will holds the textual representation of an identified method, we create a method (let's call it opMethod) that will returns the op of that method.

Mourad Abbay has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Change the name of the opMethod
 - Merge branch 'code-reflection' into opMethod
 - Apply suggestions
 - Replace opField with opMethod for identified methods

-------------

Changes:
  - all: https://git.openjdk.org/babylon/pull/299/files
  - new: https://git.openjdk.org/babylon/pull/299/files/96e02596..b198cda9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=299&range=02
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=299&range=01-02

  Stats: 10943 lines in 188 files changed: 6927 ins; 3158 del; 858 mod
  Patch: https://git.openjdk.org/babylon/pull/299.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/299/head:pull/299

PR: https://git.openjdk.org/babylon/pull/299

From psandoz at openjdk.org  Thu Dec 19 18:50:46 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 19 Dec 2024 18:50:46 GMT
Subject: [code-reflection] RFR: Support for Generalized Buffer Type in Hat
 SPIR-V Backend
In-Reply-To: <iciWNN7LHxLpsttDq-x-pqDfWHCPA4Xw0_qvz5DnY6w=.5c8b1360-e5d9-4b75-8093-c943b1518c06@github.com>
References: <iciWNN7LHxLpsttDq-x-pqDfWHCPA4Xw0_qvz5DnY6w=.5c8b1360-e5d9-4b75-8093-c943b1518c06@github.com>
Message-ID: <oHLow5F7C3nSTIGOfMLlBki8_9kPJB_9BHcl70-WwdA=.701a206c-19f2-4900-966f-94415d79d148@github.com>

On Mon, 16 Dec 2024 22:02:23 GMT, hanklo6 <duke at openjdk.org> wrote:

> This PR introduces support for generalized buffer by creating SPIRV type structure and arrays in the generated module. Most of the implementation references the OpenCL Hat builder. The SPIR-V module assumes the same memory layout as the java buffer object, provided there is not additional customized padding between fields. Also, generated dependent functions from callgraph instead of using code model to resolve the issue where private functions can't be accessed.
> 
> The blackscholes, mandel, and violajones examples now run successfully. However, the violajones example still gets wrong value when accessing `threshold` from `stage` inside `isAFaceStage` function, so I currently update the condition to `sumOfThisStage > threshold`.
> 
> For machines that don't have `float64` capability, enable `FP64` emulation by setting the environment variable: `OverrideDefaultFP64Settings=1` and `IGC_EnableDPEmulation=1` before running. For more details: https://github.com/intel/compute-runtime/blob/master/opencl/doc/FAQ.md#feature-double-precision-emulation-fp64

Nice work. Do the changes you made to the violajones example suggest that there is a mismatch between the layout of the buffer interfaces described by `MemoryLayout` and the SPIRV type structure?

-------------

PR Comment: https://git.openjdk.org/babylon/pull/298#issuecomment-2555546993

From psandoz at openjdk.org  Thu Dec 19 18:57:52 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 19 Dec 2024 18:57:52 GMT
Subject: [code-reflection] RFR: Support for Generalized Buffer Type in Hat
 SPIR-V Backend
In-Reply-To: <iciWNN7LHxLpsttDq-x-pqDfWHCPA4Xw0_qvz5DnY6w=.5c8b1360-e5d9-4b75-8093-c943b1518c06@github.com>
References: <iciWNN7LHxLpsttDq-x-pqDfWHCPA4Xw0_qvz5DnY6w=.5c8b1360-e5d9-4b75-8093-c943b1518c06@github.com>
Message-ID: <VLaK4ntyK91X14vnPG1mqE-AUuF78TdW2mgnfZbFT1c=.c54fa3d5-3583-4666-a79a-40bd5c4f9738@github.com>

On Mon, 16 Dec 2024 22:02:23 GMT, hanklo6 <duke at openjdk.org> wrote:

> This PR introduces support for generalized buffer by creating SPIRV type structure and arrays in the generated module. Most of the implementation references the OpenCL Hat builder. The SPIR-V module assumes the same memory layout as the java buffer object, provided there is not additional customized padding between fields. Also, generated dependent functions from callgraph instead of using code model to resolve the issue where private functions can't be accessed.
> 
> The blackscholes, mandel, and violajones examples now run successfully. However, the violajones example still gets wrong value when accessing `threshold` from `stage` inside `isAFaceStage` function, so I currently update the condition to `sumOfThisStage > threshold`.
> 
> For machines that don't have `float64` capability, enable `FP64` emulation by setting the environment variable: `OverrideDefaultFP64Settings=1` and `IGC_EnableDPEmulation=1` before running. For more details: https://github.com/intel/compute-runtime/blob/master/opencl/doc/FAQ.md#feature-double-precision-emulation-fp64

hat/backends/spirv/src/main/java/intel/code/spirv/SpirvModuleGenerator.java line 238:

> 236:     }
> 237: 
> 238:     private void generateTypeDeclaration(Object... args) {

@grfrost can better advise, but if possible it might be better to work directly off the `MemoryLayout` objects used by the buffer, that's also a more general solution.

-------------

PR Review Comment: https://git.openjdk.org/babylon/pull/298#discussion_r1892996224

From duke at openjdk.org  Thu Dec 19 20:20:48 2024
From: duke at openjdk.org (hanklo6)
Date: Thu, 19 Dec 2024 20:20:48 GMT
Subject: [code-reflection] RFR: Support for Generalized Buffer Type in Hat
 SPIR-V Backend
In-Reply-To: <oHLow5F7C3nSTIGOfMLlBki8_9kPJB_9BHcl70-WwdA=.701a206c-19f2-4900-966f-94415d79d148@github.com>
References: <iciWNN7LHxLpsttDq-x-pqDfWHCPA4Xw0_qvz5DnY6w=.5c8b1360-e5d9-4b75-8093-c943b1518c06@github.com>
 <oHLow5F7C3nSTIGOfMLlBki8_9kPJB_9BHcl70-WwdA=.701a206c-19f2-4900-966f-94415d79d148@github.com>
Message-ID: <pbLdUbCsAAnD8J2ZAGpz1PK72BORZ8MEwjSF1C-todI=.dadbcfa9-7c94-4128-a5db-951ca563fdb3@github.com>

On Thu, 19 Dec 2024 18:47:51 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> This PR introduces support for generalized buffer by creating SPIRV type structure and arrays in the generated module. Most of the implementation references the OpenCL Hat builder. The SPIR-V module assumes the same memory layout as the java buffer object, provided there is not additional customized padding between fields. Also, generated dependent functions from callgraph instead of using code model to resolve the issue where private functions can't be accessed.
>> 
>> The blackscholes, mandel, and violajones examples now run successfully. However, the violajones example still gets wrong value when accessing `threshold` from `stage` inside `isAFaceStage` function, so I currently update the condition to `sumOfThisStage > threshold`.
>> 
>> For machines that don't have `float64` capability, enable `FP64` emulation by setting the environment variable: `OverrideDefaultFP64Settings=1` and `IGC_EnableDPEmulation=1` before running. For more details: https://github.com/intel/compute-runtime/blob/master/opencl/doc/FAQ.md#feature-double-precision-emulation-fp64
>
> Nice work. Do the changes you made to the violajones example suggest that there is a mismatch between the layout of the buffer interfaces described by `MemoryLayout` and the SPIRV type structure?

@PaulSandoz  It might be the reason. However, I examined other fields in Stage, and only the `threshold` value differs, while other fields like `id`, `firstTreeId`, and `treeCount` remain unchanged.

The issue arises when passing the object to another SPIR-V function throught parameter, causing certain values within it to change unexpectedly. However, directly accessing the object field inside another object works correctly. I think it might be due to an incorrect storage class or some hidden mechanism in SPIR-V parameter handling that I don't fully understand.

-------------

PR Comment: https://git.openjdk.org/babylon/pull/298#issuecomment-2555699388

From psandoz at openjdk.org  Thu Dec 19 20:43:51 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 19 Dec 2024 20:43:51 GMT
Subject: [code-reflection] RFR: Support for Generalized Buffer Type in Hat
 SPIR-V Backend
In-Reply-To: <oHLow5F7C3nSTIGOfMLlBki8_9kPJB_9BHcl70-WwdA=.701a206c-19f2-4900-966f-94415d79d148@github.com>
References: <iciWNN7LHxLpsttDq-x-pqDfWHCPA4Xw0_qvz5DnY6w=.5c8b1360-e5d9-4b75-8093-c943b1518c06@github.com>
 <oHLow5F7C3nSTIGOfMLlBki8_9kPJB_9BHcl70-WwdA=.701a206c-19f2-4900-966f-94415d79d148@github.com>
Message-ID: <saXzO-QfYxwden6nzk2SIOufwG6Kqr5up6tGyz6y0rM=.4e0246e1-373f-4b28-b16d-731a887c5c8a@github.com>

On Thu, 19 Dec 2024 18:47:51 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> This PR introduces support for generalized buffer by creating SPIRV type structure and arrays in the generated module. Most of the implementation references the OpenCL Hat builder. The SPIR-V module assumes the same memory layout as the java buffer object, provided there is not additional customized padding between fields. Also, generated dependent functions from callgraph instead of using code model to resolve the issue where private functions can't be accessed.
>> 
>> The blackscholes, mandel, and violajones examples now run successfully. However, the violajones example still gets wrong value when accessing `threshold` from `stage` inside `isAFaceStage` function, so I currently update the condition to `sumOfThisStage > threshold`.
>> 
>> For machines that don't have `float64` capability, enable `FP64` emulation by setting the environment variable: `OverrideDefaultFP64Settings=1` and `IGC_EnableDPEmulation=1` before running. For more details: https://github.com/intel/compute-runtime/blob/master/opencl/doc/FAQ.md#feature-double-precision-emulation-fp64
>
> Nice work. Do the changes you made to the violajones example suggest that there is a mismatch between the layout of the buffer interfaces described by `MemoryLayout` and the SPIRV type structure?

> @PaulSandoz It might be the reason. However, I examined other fields in Stage, and only the `threshold` value differs, while other fields like `id`, `firstTreeId`, and `treeCount` remain unchanged.
> 
> The issue arises when passing the object to another SPIR-V function throught parameter, causing certain values within it to change unexpectedly. However, directly accessing the object field inside another object works correctly. I think it might be due to an incorrect storage class or some hidden mechanism in SPIR-V parameter handling that I don't fully understand.

Ok, certainly that's odd given one would presumably expect the passing of pointers. I hope its not some nasty SPIRV compiler bug. I wonder what happens if you swap the `Cascade.Stage stage` and `Cascade cascade` method parameters?

Also, did you verify it produces the same results (with some epsilon)?

-------------

PR Comment: https://git.openjdk.org/babylon/pull/298#issuecomment-2555735422

From duke at openjdk.org  Thu Dec 19 21:19:53 2024
From: duke at openjdk.org (hanklo6)
Date: Thu, 19 Dec 2024 21:19:53 GMT
Subject: [code-reflection] RFR: Support for Generalized Buffer Type in Hat
 SPIR-V Backend
In-Reply-To: <iciWNN7LHxLpsttDq-x-pqDfWHCPA4Xw0_qvz5DnY6w=.5c8b1360-e5d9-4b75-8093-c943b1518c06@github.com>
References: <iciWNN7LHxLpsttDq-x-pqDfWHCPA4Xw0_qvz5DnY6w=.5c8b1360-e5d9-4b75-8093-c943b1518c06@github.com>
Message-ID: <XcbMVCxBEomcTmQYHMSyk6_XYjR2DH0VhHSMx7TBADs=.88c77d1e-3a0c-47fe-8881-0ca03cacfde6@github.com>

On Mon, 16 Dec 2024 22:02:23 GMT, hanklo6 <duke at openjdk.org> wrote:

> This PR introduces support for generalized buffer by creating SPIRV type structure and arrays in the generated module. Most of the implementation references the OpenCL Hat builder. The SPIR-V module assumes the same memory layout as the java buffer object, provided there is not additional customized padding between fields. Also, generated dependent functions from callgraph instead of using code model to resolve the issue where private functions can't be accessed.
> 
> The blackscholes, mandel, and violajones examples now run successfully. However, the violajones example still gets wrong value when accessing `threshold` from `stage` inside `isAFaceStage` function, so I currently update the condition to `sumOfThisStage > threshold`.
> 
> For machines that don't have `float64` capability, enable `FP64` emulation by setting the environment variable: `OverrideDefaultFP64Settings=1` and `IGC_EnableDPEmulation=1` before running. For more details: https://github.com/intel/compute-runtime/blob/master/opencl/doc/FAQ.md#feature-double-precision-emulation-fp64

I got the same result after swapping the `Cascade.Stage stage` and `Cascade cascade` method parameters. 

For verification, I compared the detected faces and the number of faces with the results from the code running on my MacOS OpenCL backend, and both detected the same faces and number of faces.

-------------

PR Comment: https://git.openjdk.org/babylon/pull/298#issuecomment-2555789594

From mcimadamore at openjdk.org  Fri Dec 20 18:28:52 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 20 Dec 2024 18:28:52 GMT
Subject: [code-reflection] RFR: Replace opField with opMethod for
 identified methods [v3]
In-Reply-To: <ejugQExWGN6N0xIWz0hZIi7ikiIK4YWbif2l9UFYDEk=.b9573a78-f177-4c4c-9eb6-85497ca1865d@github.com>
References: <4y0CgR837WbBAokzbLNUf6l5KqJrXDKuwoOuoFtZA-I=.043e5b30-17fa-4af5-bcbb-ed4c3a7cceb9@github.com>
 <ejugQExWGN6N0xIWz0hZIi7ikiIK4YWbif2l9UFYDEk=.b9573a78-f177-4c4c-9eb6-85497ca1865d@github.com>
Message-ID: <qGgUvjUSrKP57Q0Q3pZ-o3Bb_rmbO4A6HWK6BJRUkRk=.e80c23c0-0da6-4858-916a-10f713e0a7ce@github.com>

On Thu, 19 Dec 2024 18:36:28 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> In this PR, instead of creating a field that will holds the textual representation of an identified method, we create a method (let's call it opMethod) that will returns the op of that method.
>
> Mourad Abbay has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Change the name of the opMethod
>  - Merge branch 'code-reflection' into opMethod
>  - Apply suggestions
>  - Replace opField with opMethod for identified methods

Marked as reviewed by mcimadamore (Reviewer).

src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/CodeReflectionSymbols.java line 79:

> 77:         syms.synthesizeEmptyInterfaceIfMissing(quotedType);
> 78:         syms.synthesizeEmptyInterfaceIfMissing(quotableType);
> 79:         funcOpType = syms.enterClass(jdk_incubator_code, "jdk.incubator.code.op.CoreOp$FuncOp");

Move this close to `opType`

-------------

PR Review: https://git.openjdk.org/babylon/pull/299#pullrequestreview-2518110139
PR Review Comment: https://git.openjdk.org/babylon/pull/299#discussion_r1894258933

From mabbay at openjdk.org  Wed Dec 25 08:05:37 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 25 Dec 2024 08:05:37 GMT
Subject: git: openjdk/babylon: code-reflection: Replace opField with opMethod
 for identified methods
Message-ID: <062f0c31-5913-419c-bc3f-d0b7ed56f81c@openjdk.org>

Changeset: 53ac6b50
Branch: code-reflection
Author:    Mourad Abbay <mabbay at openjdk.org>
Date:      2024-12-25 08:04:46 +0000
URL:       https://git.openjdk.org/babylon/commit/53ac6b50554909b9943b39947f28c36f001b05d4

Replace opField with opMethod for identified methods

Reviewed-by: mcimadamore

! src/jdk.incubator.code/share/classes/jdk/incubator/code/Op.java
! src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/CodeReflectionSymbols.java
! src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/ReflectMethods.java
! src/jdk.incubator.code/share/classes/jdk/incubator/code/parser/OpParser.java


From mabbay at openjdk.org  Wed Dec 25 08:08:16 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 25 Dec 2024 08:08:16 GMT
Subject: [code-reflection] RFR: Replace opField with opMethod for
 identified methods [v4]
In-Reply-To: <4y0CgR837WbBAokzbLNUf6l5KqJrXDKuwoOuoFtZA-I=.043e5b30-17fa-4af5-bcbb-ed4c3a7cceb9@github.com>
References: <4y0CgR837WbBAokzbLNUf6l5KqJrXDKuwoOuoFtZA-I=.043e5b30-17fa-4af5-bcbb-ed4c3a7cceb9@github.com>
Message-ID: <s0_vLxkC3Kz36sd1fSIITx9yPdM7LSfK62jWQD73yYk=.10d69726-3cd6-484b-881b-050741db7717@github.com>

> In this PR, instead of creating a field that will holds the textual representation of an identified method, we create a method (let's call it opMethod) that will returns the op of that method.

Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestion

-------------

Changes:
  - all: https://git.openjdk.org/babylon/pull/299/files
  - new: https://git.openjdk.org/babylon/pull/299/files/b198cda9..2d492e97

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=299&range=03
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=299&range=02-03

  Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/babylon/pull/299.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/299/head:pull/299

PR: https://git.openjdk.org/babylon/pull/299

From mabbay at openjdk.org  Wed Dec 25 08:08:16 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 25 Dec 2024 08:08:16 GMT
Subject: [code-reflection] Integrated: Replace opField with opMethod for
 identified methods
In-Reply-To: <4y0CgR837WbBAokzbLNUf6l5KqJrXDKuwoOuoFtZA-I=.043e5b30-17fa-4af5-bcbb-ed4c3a7cceb9@github.com>
References: <4y0CgR837WbBAokzbLNUf6l5KqJrXDKuwoOuoFtZA-I=.043e5b30-17fa-4af5-bcbb-ed4c3a7cceb9@github.com>
Message-ID: <eu23ylYI94VDER1myeuyTHPd1kA-Als89uJEKjOJCQE=.800136ac-4993-4f5d-a247-a4b15c441e73@github.com>

On Thu, 19 Dec 2024 02:34:19 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> In this PR, instead of creating a field that will holds the textual representation of an identified method, we create a method (let's call it opMethod) that will returns the op of that method.

This pull request has now been integrated.

Changeset: 53ac6b50
Author:    Mourad Abbay <mabbay at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/53ac6b50554909b9943b39947f28c36f001b05d4
Stats:     55 lines in 4 files changed: 22 ins; 21 del; 12 mod

Replace opField with opMethod for identified methods

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/babylon/pull/299

From mabbay at openjdk.org  Wed Dec 25 10:30:04 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 25 Dec 2024 10:30:04 GMT
Subject: [code-reflection] RFR: Replace opField with opMethod for lambdas.
Message-ID: <hmjW-ONDok1rYtEB8rH2wBvzkB0wGsSfJguAKT6PhY8=.d8cbc3d3-84e3-4dc0-9f57-6fc75d751035@github.com>

We replace field holding the textual representation of an identified lambda with method that returns the representation of that lambda.

-------------

Commit messages:
 - Replace opField with opMethod for lambdas.

Changes: https://git.openjdk.org/babylon/pull/301/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=301&range=00
  Stats: 71 lines in 8 files changed: 13 ins; 16 del; 42 mod
  Patch: https://git.openjdk.org/babylon/pull/301.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/301/head:pull/301

PR: https://git.openjdk.org/babylon/pull/301

From mabbay at openjdk.org  Tue Dec 31 10:42:02 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Tue, 31 Dec 2024 10:42:02 GMT
Subject: [code-reflection] RFR: Make Quotable a marker interface
Message-ID: <QzcHdJuos_IDYV7Is8vmxeAXf5_wGuyyC0Sj-UjhQcw=.db07b784-2ab6-4e86-be57-6d34d0cf9498@github.com>

In this PR, we make Quotable a marker interface. This PR is based on #301.

-------------

Commit messages:
 - Make Quotable a marker interface
 - Replace opField with opMethod for lambdas.

Changes: https://git.openjdk.org/babylon/pull/302/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=302&range=00
  Stats: 154 lines in 19 files changed: 50 ins; 26 del; 78 mod
  Patch: https://git.openjdk.org/babylon/pull/302.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/302/head:pull/302

PR: https://git.openjdk.org/babylon/pull/302