New Examples: Dialects and Dynamic Function Builds #549
Conversation
|
👋 Welcome back jfumero! A progress list of the required criteria for merging this PR into |
|
@jjfumero This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be: You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 6 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
jjfumero
changed the title
openjdk
bot
added
ready
|
/integrate |
Webrevs
|
|
/integrate |
openjdk
bot
added
sponsor
|
|
||
| @Override | ||
| public Map<String, Object> externalize() { | ||
| return Map.of("", this.typeElement); |
There was a problem hiding this comment.
The typeElement is already part of the operation, it's result type so this is duplicating information. Instead consider a property of addition as an example e.g., the kind of addition for integral types like signed, unsigned, or saturating.
|
|
||
| private TypeElement typeElement; | ||
|
|
||
| MyAdd(String name, List<Value> operands, TypeElement typeElement) { |
There was a problem hiding this comment.
The operation name should not generally be something the user provides when constructing an operation. The name is for human readability in text, and the key that allows (re-)construction when parsing text back into code models. It's something that should be derived from other inputs and/or constant data. Further, its not something we should really use for pattern matching.
I would like to see if we could remove the name from the state of Op. OpWriter of course needs it. Maybe by default the written operation name is the operation (fully qualified) class name, and implementations can override it maybe via a separate interface. We might be able to group the name and externalization of state under one concept for reading/parsing.
|
|
||
| @Override | ||
| public Map<String, Object> externalize() { | ||
| return Map.of("", this.typeDescriptor); |
There was a problem hiding this comment.
This can be the name of the function to invoke, which you are currently using as the operation name.
|
Thanks Paul for the feedback. I will make some modifications to adapt to these changes. |
openjdk
bot
removed
ready
openjdk
bot
added
ready
|
/integrate |
|
Going to push as commit a9055a8.
Your commit was automatically rebased without conflicts. |
openjdk
bot
removed
ready
DialectSample: Example of how to extends the code reflectionOpto create a new dialect.DynamicFunctionBuild: Example of how to create a new function dynamically to compute the inverse of a square root. The code model is built dynamically for a new method and it is evaluated in theInterpreter.How to run?
Run DialectWithInvoke
Run DialectFMAOp
Run DynamicFunctionBuild
Progress
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/babylon.git pull/549/head:pull/549$ git checkout pull/549Update a local copy of the PR:
$ git checkout pull/549$ git pull https://git.openjdk.org/babylon.git pull/549/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 549View PR using the GUI difftool:
$ git pr show -t 549Using diff file
Download this PR as a diff file:
https://git.openjdk.org/babylon/pull/549.diff
Using Webrev
Link to Webrev Comment