From e5c2b3b92e4264d6e6d30b6f257f08db6d7ce212 Mon Sep 17 00:00:00 2001 From: Daryl Maier Date: Tue, 12 Nov 2024 08:19:15 -0500 Subject: [PATCH] Update Eclipse OMR GitHub links to new eclipse-omr organization Signed-off-by: Daryl Maier --- CONTRIBUTING.md | 84 ++++---- NOTICE.md | 2 +- README.md | 4 +- buildenv/jenkins/README.md | 12 +- buildenv/jenkins/refRepoUpdater.groovy | 2 +- compiler/README.md | 2 +- compiler/codegen/OMRRealRegister.hpp | 12 +- compiler/optimizer/FieldPrivatizer.cpp | 2 +- .../optimizer/RedundantAsyncCheckRemoval.cpp | 2 +- compiler/optimizer/ValuePropagationCommon.cpp | 4 +- compiler/z/codegen/OMRCodeGenerator.cpp | 2 +- compiler/z/codegen/OMRTreeEvaluator.cpp | 6 +- doc/BuildingWithCMake.md | 14 +- doc/GitCrashCourse.md | 26 +-- doc/GuideForCommitters.md | 8 +- doc/compiler/CompilerOptions.md | 8 +- doc/compiler/ProblemDetermination.md | 12 +- .../extensible_classes/Extensible_Classes.md | 4 +- doc/compiler/il/MainlineAndOutOfLineCode.md | 2 +- doc/compiler/optimizer/DataFlowEngine.md | 42 ++-- doc/compiler/optimizer/Inliner.md | 194 +++++++++--------- .../optimizer/IntroLoopOptimizations.md | 6 +- doc/compiler/optimizer/IntroReadLogFile.md | 24 +-- doc/compiler/optimizer/ValuePropagation.md | 16 +- doc/compiler/osr/OSR.md | 4 +- doc/compiler/riscv/Building.md | 4 +- doc/compiler/x/OpCodeEncoding.md | 6 +- doc/diagnostics/CallingConventions.md | 2 +- doc/images/addition-of-a-fork.svg | 2 +- doc/images/distributed-vcs-model.svg | 2 +- doc/images/omr-dev-workflow.svg | 2 +- fvtest/tril/README.md | 8 +- .../apigen/schema/api-class.schema.json | 2 +- .../apigen/schema/api-field.schema.json | 2 +- .../apigen/schema/api-service.schema.json | 2 +- jitbuilder/apigen/schema/api-type.schema.json | 2 +- jitbuilder/apigen/schema/api.schema.json | 2 +- jitbuilder/release/README.md | 6 +- scripts/commit-msg | 4 +- 39 files changed, 270 insertions(+), 270 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 2137f92ac1..fdc2d36f0b 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -37,7 +37,7 @@ This project uses GitHub Issues to track ongoing development, discuss project plans, and keep track of bugs. Be sure to search for existing issues before you create another one. -Visit [our Issues page on GitHub to search and submit](https://github.com/eclipse/omr/issues) +Visit [our Issues page on GitHub to search and submit](https://github.com/eclipse-omr/omr/issues) ### Labelling @@ -47,62 +47,62 @@ may have multiple labels, as many as needed to provide adequate categorization. A subset of the labels are documented below. -* [**`good first issue`**](https://github.com/eclipse/omr/labels/good%20first%20issue) generally +* [**`good first issue`**](https://github.com/eclipse-omr/omr/labels/good%20first%20issue) generally refers to a task that would be suitable for someone new to the project with little experience with either the technology or even open-source projects and processes. They are intended for anyone who wants to gently get their feet wet on building, testing, or familiarizing themselves with part of the code base. -* [**`bug`**](https://github.com/eclipse/omr/labels/bug) issues are functional +* [**`bug`**](https://github.com/eclipse-omr/omr/labels/bug) issues are functional problems, errors or unexpected behaviour. -* [**`build/configure`**](https://github.com/eclipse/omr/labels/build%20%2F%20configure) +* [**`build/configure`**](https://github.com/eclipse-omr/omr/labels/build%20%2F%20configure) labels are used to describe issues with the build and configure system (e.g., makefiles, autotools configure). -* [**`ci`**](https://github.com/eclipse/omr/labels/ci) labels are used for +* [**`ci`**](https://github.com/eclipse-omr/omr/labels/ci) labels are used for issues and enhancements with the continuous integration system for pull request testing (e.g., Jenkins, Azure, etc.) -* [**`cmake`**](https://github.com/eclipse/omr/labels/cmake) labels are similar +* [**`cmake`**](https://github.com/eclipse-omr/omr/labels/cmake) labels are similar to build/configure but they apply specifically to the CMake configuration. -* [**`compiler arch review`**](https://github.com/eclipse/omr/labels/compiler%20arch%20review) +* [**`compiler arch review`**](https://github.com/eclipse-omr/omr/labels/compiler%20arch%20review) labels are used to indicate a review of this issue or pull request at the - [OMR Compiler Architecture meeting](https://github.com/eclipse/omr/issues/2316) + [OMR Compiler Architecture meeting](https://github.com/eclipse-omr/omr/issues/2316) is requested prior to committing. -* [**`documentation`**](https://github.com/eclipse/omr/labels/documentation) +* [**`documentation`**](https://github.com/eclipse-omr/omr/labels/documentation) labels are used for issues or enhancements to the documentation (either in the source code itself or stand-alone documentation files). -* [**`epic`**](https://github.com/eclipse/omr/labels/epic) issues are used to +* [**`epic`**](https://github.com/eclipse-omr/omr/labels/epic) issues are used to group together related issues and to track larger goals in the project across issues. -* [**`GSoC Project`**](https://github.com/eclipse/omr/labels/GSoC%20project) +* [**`GSoC Project`**](https://github.com/eclipse-omr/omr/labels/GSoC%20project) labels are for potential ideas for Google Summer Of Code projects. -* [**`help wanted`**](https://github.com/eclipse/omr/labels/help%20wanted) +* [**`help wanted`**](https://github.com/eclipse-omr/omr/labels/help%20wanted) issues have value to the project but no immediate human resources to undertake it. Those that are looking to complete a task that someone isn't already working on can consider these. -* [**`license`**](https://github.com/eclipse/omr/labels/license) labels are +* [**`license`**](https://github.com/eclipse-omr/omr/labels/license) labels are used to annotate issues concerning the source code license. -* [**`meeting`**](https://github.com/eclipse/omr/labels/meeting) labels are +* [**`meeting`**](https://github.com/eclipse-omr/omr/labels/meeting) labels are used to annotate issues pertaining to project meeting agendas or minutes. -* [**`toolchain bug`**](https://github.com/eclipse/omr/labels/toolchain%20bug) +* [**`toolchain bug`**](https://github.com/eclipse-omr/omr/labels/toolchain%20bug) labels are used to document issues or pull requests that describe or implement a workaround to a bug in the development toolchain (such as the compiler) used to build OMR. Toolchain workarounds should be temporary in nature, and the intention of this label is to make such workarounds easy to discover in the future lest they be lost in the code. -* [**`tooling`**](https://github.com/eclipse/omr/labels/tooling) labels are for +* [**`tooling`**](https://github.com/eclipse-omr/omr/labels/tooling) labels are for issues concerning support tooling needed to support any of the code or processes within the project. @@ -111,39 +111,39 @@ Eclipse OMR technology component they affect. For instance, | Label | Component | Principal Directories | | :---- | :---- | :---- | -[**`comp:compiler`**](https://github.com/eclipse/omr/labels/comp%3Acompiler) | Compiler | `compiler` -[**`comp:core`**](https://github.com/eclipse/omr/labels/comp%3Acore) | Core OMR functionality | `include_code`, `omr` -[**`comp:diagnostic`**](https://github.com/eclipse/omr/labels/comp%3Adiagnostic) | Diagnostic services | `ddr` -[**`comp:doc`**](https://github.com/eclipse/omr/labels/comp%3Adoc) | OMR documentation | `doc` -[**`comp:gc`**](https://github.com/eclipse/omr/labels/comp%3Agc) | Garbage collector | `gc` -[**`comp:glue`**](https://github.com/eclipse/omr/labels/comp%3Aglue) | Glue code | `glue` -[**`comp:jitbuilder`**](https://github.com/eclipse/omr/labels/comp%3Ajitbuilder) | JitBuilder | `jitbuilder` -[**`comp:port`**](https://github.com/eclipse/omr/labels/comp%3Aport) | Port library | `port` -[**`comp:test`**](https://github.com/eclipse/omr/labels/comp%3Atest) | Unit tests and testing framework | `fvtest` -[**`comp:thread`**](https://github.com/eclipse/omr/labels/comp%3Athread) | Thread library | `thread` -[**`comp:tril`**](https://github.com/eclipse/omr/labels/comp%3Atril) | Tril infrastructure and tests | `fvtest/tril` -[**`comp:utilities`**](https://github.com/eclipse/omr/labels/comp%3Autil) | OMR utilities | `util` +[**`comp:compiler`**](https://github.com/eclipse-omr/omr/labels/comp%3Acompiler) | Compiler | `compiler` +[**`comp:core`**](https://github.com/eclipse-omr/omr/labels/comp%3Acore) | Core OMR functionality | `include_code`, `omr` +[**`comp:diagnostic`**](https://github.com/eclipse-omr/omr/labels/comp%3Adiagnostic) | Diagnostic services | `ddr` +[**`comp:doc`**](https://github.com/eclipse-omr/omr/labels/comp%3Adoc) | OMR documentation | `doc` +[**`comp:gc`**](https://github.com/eclipse-omr/omr/labels/comp%3Agc) | Garbage collector | `gc` +[**`comp:glue`**](https://github.com/eclipse-omr/omr/labels/comp%3Aglue) | Glue code | `glue` +[**`comp:jitbuilder`**](https://github.com/eclipse-omr/omr/labels/comp%3Ajitbuilder) | JitBuilder | `jitbuilder` +[**`comp:port`**](https://github.com/eclipse-omr/omr/labels/comp%3Aport) | Port library | `port` +[**`comp:test`**](https://github.com/eclipse-omr/omr/labels/comp%3Atest) | Unit tests and testing framework | `fvtest` +[**`comp:thread`**](https://github.com/eclipse-omr/omr/labels/comp%3Athread) | Thread library | `thread` +[**`comp:tril`**](https://github.com/eclipse-omr/omr/labels/comp%3Atril) | Tril infrastructure and tests | `fvtest/tril` +[**`comp:utilities`**](https://github.com/eclipse-omr/omr/labels/comp%3Autil) | OMR utilities | `util` Further classification by processor architecture, operating system, and bitness can be achieved with the following labels: -* [**`arch:aarch32`**](https://github.com/eclipse/omr/labels/arch%3Aaarch32) -* [**`arch:aarch64`**](https://github.com/eclipse/omr/labels/arch%3Aaarch64) -* [**`arch:power`**](https://github.com/eclipse/omr/labels/arch%3Apower) -* [**`arch:riscv`**](https://github.com/eclipse/omr/labels/arch%3Ariscv) -* [**`arch:x86`**](https://github.com/eclipse/omr/labels/arch%3Ax86) -* [**`arch:z`**](https://github.com/eclipse/omr/labels/arch%3Az) +* [**`arch:aarch32`**](https://github.com/eclipse-omr/omr/labels/arch%3Aaarch32) +* [**`arch:aarch64`**](https://github.com/eclipse-omr/omr/labels/arch%3Aaarch64) +* [**`arch:power`**](https://github.com/eclipse-omr/omr/labels/arch%3Apower) +* [**`arch:riscv`**](https://github.com/eclipse-omr/omr/labels/arch%3Ariscv) +* [**`arch:x86`**](https://github.com/eclipse-omr/omr/labels/arch%3Ax86) +* [**`arch:z`**](https://github.com/eclipse-omr/omr/labels/arch%3Az)
-* [**`os:aix`**](https://github.com/eclipse/omr/labels/os%3Aaix) -* [**`os:linux`**](https://github.com/eclipse/omr/labels/os%3Alinux) -* [**`os:macos`**](https://github.com/eclipse/omr/labels/os%3Amacos) -* [**`os:windows`**](https://github.com/eclipse/omr/labels/os%3Awindows) -* [**`os:zos`**](https://github.com/eclipse/omr/labels/os%3Azos) +* [**`os:aix`**](https://github.com/eclipse-omr/omr/labels/os%3Aaix) +* [**`os:linux`**](https://github.com/eclipse-omr/omr/labels/os%3Alinux) +* [**`os:macos`**](https://github.com/eclipse-omr/omr/labels/os%3Amacos) +* [**`os:windows`**](https://github.com/eclipse-omr/omr/labels/os%3Awindows) +* [**`os:zos`**](https://github.com/eclipse-omr/omr/labels/os%3Azos)
-* [**`bits:32`**](https://github.com/eclipse/omr/labels/bits%3A32) -* [**`bits:64`**](https://github.com/eclipse/omr/labels/bits%3A64) +* [**`bits:32`**](https://github.com/eclipse-omr/omr/labels/bits%3A32) +* [**`bits:64`**](https://github.com/eclipse-omr/omr/labels/bits%3A64) ## Submitting a contribution @@ -189,7 +189,7 @@ Following these guidelines will help us to merge your pull requests smoothly: or, in the opinion of a committer, a fundamental element of compiler infrastructure, a committer will request that this pull request be presented at an upcoming - [OMR Compiler Architecture meeting](https://github.com/eclipse/omr/issues/2316) + [OMR Compiler Architecture meeting](https://github.com/eclipse-omr/omr/issues/2316) to invite community discussion prior to merging. Issues of the same nature may also be asked to be discussed before the same architecture meeting prior to producing a pull request. diff --git a/NOTICE.md b/NOTICE.md index 6856560c70..e12e3e3afe 100644 --- a/NOTICE.md +++ b/NOTICE.md @@ -179,7 +179,7 @@ and such source code may be obtained at http://www.eclipse.org. ## Source Code This project maintains the following source code repository: -https://github.com/eclipse/omr.git +https://github.com/eclipse-omr/omr.git ## Third-party Content diff --git a/README.md b/README.md index 80a8288e5c..e655a4293c 100644 --- a/README.md +++ b/README.md @@ -115,7 +115,7 @@ We operate under the [Eclipse Code of Conduct][coc] to promote fairness, opennes * Join the Eclipse OMR developer community [mailing list](https://accounts.eclipse.org/mailing-list/omr-dev). The community primarily uses this list for project announcements and administrative discussions amongst committers. Questions are welcome here as well. -* Ask a question or start a discussion via a [GitHub issue](https://github.com/eclipse/omr/issues). +* Ask a question or start a discussion via a [GitHub issue](https://github.com/eclipse-omr/omr/issues). Contributing ============ @@ -124,7 +124,7 @@ If you would like to contribute to OMR, check out the [contributing guide][contr We also have curated a set of [good first issues][beg] for newcomers to tackle. [contrib]: CONTRIBUTING.md -[beg]: https://github.com/eclipse/omr/issues?q=is%3Aopen+is%3Aissue+label%3A%22good%20first%20issue%22 +[beg]: https://github.com/eclipse-omr/omr/issues?q=is%3Aopen+is%3Aissue+label%3A%22good%20first%20issue%22 How Do I Use it? ================ diff --git a/buildenv/jenkins/README.md b/buildenv/jenkins/README.md index a2a5583651..750702d087 100644 --- a/buildenv/jenkins/README.md +++ b/buildenv/jenkins/README.md @@ -32,14 +32,14 @@ From the [Builds view](https://ci.eclipse.org/omr/view/Builds/), on the left men 1. General 1. Discard old builds -> Max # of builds to keep: `25` - 1. GitHub project -> Project url: `https://github.com/eclipse/omr/` + 1. GitHub project -> Project url: `https://github.com/eclipse-omr/omr/` 1. This project is parameterized -> Choice Parameter -> Name: `BUILDSPEC` -> Choices: `` (The matching SPEC name) 1. Build Triggers 1. Generic Webhook Trigger (defaults should be fine) 1. Pipeline 1. Definition: Pipeline script from SCM 1. SCM: Git - 1. Repositories -> Repository URL: `https://github.com/eclipse/omr.git` + 1. Repositories -> Repository URL: `https://github.com/eclipse-omr/omr.git` 1. Branches to build: `/refs/heads/master` 1. Script Path: `buildenv/jenkins/omrbuild.groovy` 1. Lightweight checkout: `true` @@ -49,7 +49,7 @@ From the [Builds view](https://ci.eclipse.org/omr/view/Builds/), on the left men From the [Pull Requests view](https://ci.eclipse.org/omr/view/Pull%20Requests/), on the left menu select [New Item](https://ci.eclipse.org/omr/view/Pull%20Requests/newJob). Name the job based on the following convention `PullRequest-` (eg. `PullRequest-linux_x86-64`. See [omrbuild.groovy](./omrbuild.groovy) for full `SPEC` list). Select `Pipeline` as the job type and then click `OK`. Setup the following in the job config. 1. General - 1. GitHub project -> Project url: `https://github.com/eclipse/omr/` + 1. GitHub project -> Project url: `https://github.com/eclipse-omr/omr/` 1. This project is parameterized -> Choice Parameter -> Name: `BUILDSPEC` -> Choices: `` (The matching SPEC name) 1. Build Triggers 1. GitHub Pull Request Builder @@ -64,7 +64,7 @@ From the [Pull Requests view](https://ci.eclipse.org/omr/view/Pull%20Requests/), 1. Definition: Pipeline script from SCM 1. SCM: Git 1. Repositories - 1. Repository URL: `https://github.com/eclipse/omr.git` + 1. Repository URL: `https://github.com/eclipse-omr/omr.git` 1. Advanced -> Refspec: `+refs/pull/${ghprbPullId}/merge:refs/remotes/origin/pr/${ghprbPullId}/merge` 1. Branches to build: `${sha1}` 1. Additional Behaviours @@ -101,7 +101,7 @@ Configuring Jenkins to pull the pipeline scripts from Git on z/OS is a non-trivi Fetching changes from the remote Git repository Cleaning workspace ERROR: Error fetching remote repo 'origin' -hudson.plugins.git.GitException: Failed to fetch from https://github.com/eclipse/omr.git +hudson.plugins.git.GitException: Failed to fetch from https://github.com/eclipse-omr/omr.git at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:894) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192) @@ -114,7 +114,7 @@ hudson.plugins.git.GitException: Failed to fetch from https://github.com/eclipse at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) -Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --progress https://github.com/eclipse/omr.git +refs/heads/*:refs/remotes/origin/*" returned status code 128: +Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --progress https://github.com/eclipse-omr/omr.git +refs/heads/*:refs/remotes/origin/*" returned status code 128: stdout: stderr: fatal: Unable to find remote helper for 'https' ``` diff --git a/buildenv/jenkins/refRepoUpdater.groovy b/buildenv/jenkins/refRepoUpdater.groovy index 57fc06118d..5f666534fb 100644 --- a/buildenv/jenkins/refRepoUpdater.groovy +++ b/buildenv/jenkins/refRepoUpdater.groovy @@ -55,7 +55,7 @@ def refresh() { dir("${HOME}/gitcache") { sh ''' git init --bare - git config remote.omr.url https://github.com/eclipse/omr.git + git config remote.omr.url https://github.com/eclipse-omr/omr.git git config remote.omr.fetch +refs/heads/*:refs/remotes/omr/* git fetch omr ''' diff --git a/compiler/README.md b/compiler/README.md index ae979b4aab..ee4e54081e 100644 --- a/compiler/README.md +++ b/compiler/README.md @@ -104,7 +104,7 @@ extensible class representation (see [*extensible classes*](../doc/compiler/exte At present, the use of the `TR` namespace for the public API is largely aspirational as much of the code appears as it did when it was first contributed. The epic to track the work to migrate components of the OMR compiler public API to the `TR` -namespace is issue [#3519](https://github.com/eclipse/omr/issues/3519). +namespace is issue [#3519](https://github.com/eclipse-omr/omr/issues/3519). Throughout the current compiler code, you may encounter references that are in the global namespace but whose identifiers are prefixed simply with `TR_`. This is inconsistent with the namespace convention just described and they are diff --git a/compiler/codegen/OMRRealRegister.hpp b/compiler/codegen/OMRRealRegister.hpp index b856c1a599..0a14e7201d 100644 --- a/compiler/codegen/OMRRealRegister.hpp +++ b/compiler/codegen/OMRRealRegister.hpp @@ -72,16 +72,16 @@ class OMR_EXTENSIBLE RealRegister : public TR::Register } RegMask; // PseudoRegisters are the union of all hardware backed registers (ex. GPR0) - // and constructs such as TR::RealRegister::NoReg or TR::RealRegister::AssignAny. - // These pseudo registers are used to assign register dependencies during the + // and constructs such as TR::RealRegister::NoReg or TR::RealRegister::AssignAny. + // These pseudo registers are used to assign register dependencies during the // Register Allocation phase. The enum below is meant to hold all pseudo registers. - // However, to avoid compilation failures, we cannot include + // However, to avoid compilation failures, we cannot include // codegen/RealRegisterEnum.hpp again. In order to include it twice, these two enums // must be scoped. However, not all of our minimum compiler toolchains support this - // feature yet (MSVC 2010). So we only include PseudoRegisterEnum below, and cast any - // RegNum to RegDep when using it to set a register dependency. If MSVC 2010 support is + // feature yet (MSVC 2010). So we only include PseudoRegisterEnum below, and cast any + // RegNum to RegDep when using it to set a register dependency. If MSVC 2010 support is // no longer required, then this can be cleaned up by using scoped enums instead. An issue - // to track this is open here: https://github.com/eclipse/omr/issues/2590 + // to track this is open here: https://github.com/eclipse-omr/omr/issues/2590 typedef enum { #include "codegen/PseudoRegisterEnum.hpp" diff --git a/compiler/optimizer/FieldPrivatizer.cpp b/compiler/optimizer/FieldPrivatizer.cpp index c1f61e5cbc..df8df54beb 100644 --- a/compiler/optimizer/FieldPrivatizer.cpp +++ b/compiler/optimizer/FieldPrivatizer.cpp @@ -497,7 +497,7 @@ bool TR_FieldPrivatizer::containsEscapePoints(TR_Structure *structure, bool &con // privatized must be of the expected type in the loop, and that // ensures any conditional access in the original loop is handled // correctly. This follow on work will be performed under OMR issue - // + // // if (currentNode->exceptionsRaised() || currentNode->isTheVirtualGuardForAGuardedInlinedCall() diff --git a/compiler/optimizer/RedundantAsyncCheckRemoval.cpp b/compiler/optimizer/RedundantAsyncCheckRemoval.cpp index 1a4e426fce..0b4bbb0b32 100644 --- a/compiler/optimizer/RedundantAsyncCheckRemoval.cpp +++ b/compiler/optimizer/RedundantAsyncCheckRemoval.cpp @@ -1289,7 +1289,7 @@ void TR_RedundantAsyncCheckRemoval::getNearestAncestors(TR_StructureSubGraphNode void TR_RedundantAsyncCheckRemoval::markAncestors(TR_StructureSubGraphNode *node, TR_StructureSubGraphNode *entry) { - return; // Disable it for performance. For more details, refer to https://github.com/eclipse/omr/pull/1138 + return; // Disable it for performance. For more details, refer to https://github.com/eclipse-omr/omr/pull/1138 if (node == entry) return; diff --git a/compiler/optimizer/ValuePropagationCommon.cpp b/compiler/optimizer/ValuePropagationCommon.cpp index e6807fe860..34b768c060 100644 --- a/compiler/optimizer/ValuePropagationCommon.cpp +++ b/compiler/optimizer/ValuePropagationCommon.cpp @@ -3961,7 +3961,7 @@ const char* transformedTargetName (TR::RecognizedMethod rm) #ifdef J9_PROJECT_SPECIFIC /** * Can be called from doDelayedTransformations when nodes may have been removed from the tree. Issue 6623 - * https://github.com/eclipse/omr/issues/6623 + * https://github.com/eclipse-omr/omr/issues/6623 */ void OMR::ValuePropagation::transformObjectCloneCall(TR::TreeTop *callTree, OMR::ValuePropagation::ObjCloneInfo *cloneInfo) { @@ -4069,7 +4069,7 @@ void OMR::ValuePropagation::transformObjectCloneCall(TR::TreeTop *callTree, OMR: /** * Can be called from doDelayedTransformations when nodes may have been removed from the tree. Issue 6623 - * https://github.com/eclipse/omr/issues/6623 + * https://github.com/eclipse-omr/omr/issues/6623 */ void OMR::ValuePropagation::transformArrayCloneCall(TR::TreeTop *callTree, OMR::ValuePropagation::ArrayCloneInfo *cloneInfo) { diff --git a/compiler/z/codegen/OMRCodeGenerator.cpp b/compiler/z/codegen/OMRCodeGenerator.cpp index 25b0e70459..1c455cd731 100644 --- a/compiler/z/codegen/OMRCodeGenerator.cpp +++ b/compiler/z/codegen/OMRCodeGenerator.cpp @@ -290,7 +290,7 @@ OMR::Z::CodeGenerator::lowerTreeIfNeeded( TR::Node* index = NULL; TR::ILOpCodes addOp, subOp, constOp; // Need to track if lowered trees are internal pointers - // For context: https://github.com/eclipse/omr/issues/4929 + // For context: https://github.com/eclipse-omr/omr/issues/4929 bool isInternalPointer = false; TR::AutomaticSymbol *pinningArrayPointer = NULL; diff --git a/compiler/z/codegen/OMRTreeEvaluator.cpp b/compiler/z/codegen/OMRTreeEvaluator.cpp index f75e4ab159..c327391ccc 100644 --- a/compiler/z/codegen/OMRTreeEvaluator.cpp +++ b/compiler/z/codegen/OMRTreeEvaluator.cpp @@ -14022,9 +14022,9 @@ OMR::Z::TreeEvaluator::bitpermuteEvaluator(TR::Node *node, TR::CodeGenerator *cg // suited for BigEndian architectures) then the Vector implementation is on par or better than the loop // unrolling technique for all array sizes. // - // More info on the measurements is available here: https://github.com/eclipse/omr/pull/2330#issuecomment-378380538 + // More info on the measurements is available here: https://github.com/eclipse-omr/omr/pull/2330#issuecomment-378380538 // The differences between the generated code for the different - // implementations can be seen here: https://github.com/eclipse/omr/pull/2330#issuecomment-378387516 + // implementations can be seen here: https://github.com/eclipse-omr/omr/pull/2330#issuecomment-378387516 static const int8_t bitPermuteConstantUnrollThreshold = 4; bool isLoadConst = length->getOpCode().isLoadConst(); @@ -16777,7 +16777,7 @@ OMR::Z::TreeEvaluator::vsetelemEvaluator(TR::Node *node, TR::CodeGenerator *cg) { // This path used to contain a call to an API which would have returned a garbage result. Rather than 100% of the // time generating an invalid sequence here which is guaranteed to crash if executed, we fail the compilation. - cg->comp()->failCompilation("Existing code relied on an unimplemented API and is thus not safe. See eclipse/omr#5937."); + cg->comp()->failCompilation("Existing code relied on an unimplemented API and is thus not safe. See eclipse-omr/omr#5937."); } else memRef = TR::MemoryReference::create(cg, valueNode); diff --git a/doc/BuildingWithCMake.md b/doc/BuildingWithCMake.md index 23ab52c51e..252af4ebe0 100644 --- a/doc/BuildingWithCMake.md +++ b/doc/BuildingWithCMake.md @@ -10,7 +10,7 @@ is available at https://www.apache.org/licenses/LICENSE-2.0. This Source Code may also be made available under the following Secondary Licenses when the conditions for such availability set forth in the Eclipse Public License, v. 2.0 are satisfied: GNU -General Public License, version 2 with the GNU Classpath +General Public License, version 2 with the GNU Classpath Exception [1] and GNU General Public License, version 2 with the OpenJDK Assembly Exception [2]. @@ -59,7 +59,7 @@ Let's consider how to use each toolchain to configure and build `OMR` with `CMak #### Common prerequisite *Perl* must be installed to configure the project. [Strawberry Perl](http://strawberryperl.com/) is absolutely -suitable for `CMake` on Windows, please do not forget to add the path to `perl.exe` (for example +suitable for `CMake` on Windows, please do not forget to add the path to `perl.exe` (for example `C:\StrawberryPerl\perl\bin`) to the `PATH` environment variable. #### Configuring the build for using MSYS2/MinGW @@ -79,8 +79,8 @@ The following components of the build tools are recommended to be installed: * Windows 10 SDK (>= 10.0.16299.0) for Desktop C++ * Visual C++ tools for CMake -**Note:** -To use the `NMake` or `Ninja` generator with *Visual C++*, `cmake` must be run from a shell that can use +**Note:** +To use the `NMake` or `Ninja` generator with *Visual C++*, `cmake` must be run from a shell that can use the compiler `cl` from the command line as it described in the document [Build C/C++ code on the command line](https://docs.microsoft.com/en-us/cpp/build/building-on-the-command-line). To enable the shell, please run @@ -208,13 +208,13 @@ Cross compiling OMR is done in two steps: * OMR_SANITIZER={address,thread,undefined} turns on one: [Address Sanitizer (ASan)][asan], [Undefined Behaviour Sanitizer (UBSan)][ubsan] or [Thread - Sanitizer (TSan)][tsan]. This only has an effect with GCC or Clang. + Sanitizer (TSan)][tsan]. This only has an effect with GCC or Clang. [ubsan]: https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html [asan]: https://github.com/google/sanitizers/wiki/AddressSanitizer -[tsan]: https://clang.llvm.org/docs/ThreadSanitizer.html +[tsan]: https://clang.llvm.org/docs/ThreadSanitizer.html ## What's next? The work here is ongoing. We are tracking development with github issue -[#993](https://github.com/eclipse/omr/issues/933). +[#993](https://github.com/eclipse-omr/omr/issues/933). diff --git a/doc/GitCrashCourse.md b/doc/GitCrashCourse.md index 6d932b1702..5a3fb6a30f 100644 --- a/doc/GitCrashCourse.md +++ b/doc/GitCrashCourse.md @@ -83,7 +83,7 @@ wizard. Before you can make any code contributions to the Eclipse OMR GitHub repository you must sign the Eclipse Contributor Agreement (ECA). This is a simple process outlined in the [Contribution Guidelines](../CONTRIBUTING.md#legal-considerations). -This step is important because the email of the author of each commit +This step is important because the email of the author of each commit must match the email you used to sign the ECA. --- @@ -172,7 +172,7 @@ Git being a distributed version control system means that there are multiple copies of the repository that can exist, but only one main repository that contributors use to submit changes, as well as for updating their own copies. For OMR, the main repository is -[`eclipse/omr`](https://github.com/eclipse/omr). +[`eclipse-omr/omr`](https://github.com/eclipse-omr/omr). Every contributor to the OMR project needs to have their own **fork** on GitHub. @@ -190,10 +190,10 @@ outlines the process. *Figure 2: OMR development workflow* In the diagram above, there are 3 copies of the repository. The `yourgithub/omr` -repository is forked from the main `eclipse/omr` repository, which you clone to +repository is forked from the main `eclipse-omr/omr` repository, which you clone to your machine as `~/omr`. On your machine, git aliases `yourgithub/omr` as `origin`. However, git does not know whether the repository you cloned is actually a fork. -In order to keep up with updates made to `eclipse/omr`, you will need to track +In order to keep up with updates made to `eclipse-omr/omr`, you will need to track changes in that repository, and call it `upstream`. Notice how there is no arrow going from `upstream` to `origin`, which means keeping your fork up to date is your responsibility. This is done by performing **fetch** from `upstream` to @@ -206,7 +206,7 @@ process. ### Issues Issues on GitHub are a great way for project contributors to collaborate. -The Eclipse OMR project makes use of [Issues](https://github.com/eclipse/omr/issues) +The Eclipse OMR project makes use of [Issues](https://github.com/eclipse-omr/omr/issues) mainly for keeping track of tasks, bugs, and discussions out in the open. Issues can be categorized using coloured labels (eg, `compiler`, @@ -380,7 +380,7 @@ right beside that to navigate to the pull request creation page. Alternatively, if you recently pushed your branch, you may see a prompt to open a Pull Request using that branch right away. -In the pull request creation page, you can see what branch of eclipse/omr +In the pull request creation page, you can see what branch of `eclipse-omr/omr` you are going to merge the commit(s) in your branch into. Your Pull Request title should describe what is being done, and the body of the Pull Request can be used to add further details about what you are doing, as @@ -445,8 +445,8 @@ commits `b1` and `b2` to `new-branch`. It would look something like this: *Figure 7: Commits added in your `new-branch`* Given the number of contributors to the Eclipse OMR project, it is likely that -more commits have been added to `eclipse/omr` resulting your base (local `master` -you created `new-branch` off of) branch being out of sync with `eclipse/omr`'s +more commits have been added to `eclipse-omr/omr` resulting your base (local `master` +you created `new-branch` off of) branch being out of sync with `eclipse-omr/omr`'s master branch that you are trying to merge your changes into. @@ -455,24 +455,24 @@ master branch that you are trying to merge your changes into. The goal of rebasing is to apply your commits on top of the current version of the branch you are trying to merge your changes into (in this case, `master` branch of -`eclipse/omr`). +`eclipse-omr/omr`). ![](./images/rebase3.svg) *Figure 9: Resulting chain of commits after rebase* Rebasing is also useful when you are trying to resolve **merge conflicts**. Merge conflicts arise when some other developer gets their commits merged into -`master` in `eclipse/omr` after the point where your branch is based on if your +`master` in `eclipse-omr/omr` after the point where your branch is based on if your commits modify/delete the lines that are affected by their commits. Git cannot automatically determine what to keep and what to discard. You will have to manually make edits to those conflicting regions in the source files. Suppose that you have a merge conflict that needs to be resolved. The first -step would be to add `eclipse/omr` repository as a remote to fetch updates -from. Let's alias the URL of `eclipse/omr` as `upstream`. +step would be to add `eclipse-omr/omr` repository as a remote to fetch updates +from. Let's alias the URL of `eclipse-omr/omr` as `upstream`. ``` -git remote add upstream https://github.com/eclipse/omr +git remote add upstream https://github.com/eclipse-omr/omr ``` Next, fetch the history from `upstream`. Performing fetch of a remote repository diff --git a/doc/GuideForCommitters.md b/doc/GuideForCommitters.md index 5e2a9c04b7..665980c49d 100644 --- a/doc/GuideForCommitters.md +++ b/doc/GuideForCommitters.md @@ -55,17 +55,17 @@ prior to merging. explanation in the pull request from the author of the rationale along with a description of the problem if the commit is not reverted. -* If a pull request modifies the [Contribution Guidelines](https://github.com/eclipse/omr/blob/master/CONTRIBUTING.md), +* If a pull request modifies the [Contribution Guidelines](https://github.com/eclipse-omr/omr/blob/master/CONTRIBUTING.md), request the author to post a detailed summary of the changes on the `omr-dev@eclipse.org` mailing list after the pull request is merged. ### Pre-Merge Checklist -* Ensure the pull request adheres to all the Eclipse OMR [Contribution Guidelines](https://github.com/eclipse/omr/blob/master/CONTRIBUTING.md) +* Ensure the pull request adheres to all the Eclipse OMR [Contribution Guidelines](https://github.com/eclipse-omr/omr/blob/master/CONTRIBUTING.md) * Ensure pull requests and issues are annotated with descriptive metadata by -attaching GitHub labels. The current set of labels can be found [here](https://github.com/eclipse/omr/labels). +attaching GitHub labels. The current set of labels can be found [here](https://github.com/eclipse-omr/omr/labels). * If you will be the primary committer, change the Assignee of the pull request to yourself. Being the primary committer does not necessarily mean you have to @@ -181,7 +181,7 @@ committer status: * Review and merge at least one pull request, or * Author and contribute at least one pull request, or * Participate in at least 25% of -[OMR Architecture Meetings](https://github.com/eclipse/omr/issues/2316), or +[OMR Architecture Meetings](https://github.com/eclipse-omr/omr/issues/2316), or * Other documented contributions not reflected in the above may be considered on a case-by-case basis by Eclipse OMR project leadership. For example, significant contributions to the design of a feature, or assistance resolving a defect, diff --git a/doc/compiler/CompilerOptions.md b/doc/compiler/CompilerOptions.md index fceaf809f6..63e68c6881 100644 --- a/doc/compiler/CompilerOptions.md +++ b/doc/compiler/CompilerOptions.md @@ -10,7 +10,7 @@ is available at https://www.apache.org/licenses/LICENSE-2.0. This Source Code may also be made available under the following Secondary Licenses when the conditions for such availability set forth in the Eclipse Public License, v. 2.0 are satisfied: GNU -General Public License, version 2 with the GNU Classpath +General Public License, version 2 with the GNU Classpath Exception [1] and GNU General Public License, version 2 with the OpenJDK Assembly Exception [2]. @@ -103,9 +103,9 @@ This section contains a subset of options available for controlling the runtime behavior of the compiler. This section does not exhaustively list all the options or their categories. To see all of the available options to control the compiler, please see the options listed in -[`/compiler/control/OMROptions.cpp`](https://github.com/eclipse/omr/blob/e2f65411e67d21ef04e2062a8945e604d82cb19e/compiler/control/OMROptions.cpp#L98) -and -[`/compiler/env/FEBase.cpp`](https://github.com/eclipse/omr/blob/e2f65411e67d21ef04e2062a8945e604d82cb19e/compiler/env/FEBase.cpp#L235) +[`/compiler/control/OMROptions.cpp`](https://github.com/eclipse-omr/omr/blob/e2f65411e67d21ef04e2062a8945e604d82cb19e/compiler/control/OMROptions.cpp#L98) +and +[`/compiler/env/FEBase.cpp`](https://github.com/eclipse-omr/omr/blob/e2f65411e67d21ef04e2062a8945e604d82cb19e/compiler/env/FEBase.cpp#L235) The purpose of listing the options in this document is to give you an insight into the level of control you have over the compiler through the options rather diff --git a/doc/compiler/ProblemDetermination.md b/doc/compiler/ProblemDetermination.md index b61ecef3ca..930c11d906 100644 --- a/doc/compiler/ProblemDetermination.md +++ b/doc/compiler/ProblemDetermination.md @@ -216,10 +216,10 @@ compilation altogether, using the `exclude=method` parameter: ### Identifying the failing Optimization. Most transformations that can be elided are guarded in the source code by a special -check called [performTransformation](https://github.com/eclipse/omr/blob/f5a790b68037be3a48b6e5c4f7e8ae6ad3e30f00/compiler/compile/OMRCompilation.hpp#L271-L274) -([more details](https://github.com/eclipse/omr/blob/8f5212d52b533cdf9d6de9c2bd8a3e01e83e8b9d/compiler/compile/OMRCompilation.hpp#L170-L226)). +check called [performTransformation](https://github.com/eclipse-omr/omr/blob/f5a790b68037be3a48b6e5c4f7e8ae6ad3e30f00/compiler/compile/OMRCompilation.hpp#L271-L274) +([more details](https://github.com/eclipse-omr/omr/blob/8f5212d52b533cdf9d6de9c2bd8a3e01e83e8b9d/compiler/compile/OMRCompilation.hpp#L170-L226)). -`performTransformation` is [enabled by option](https://github.com/eclipse/omr/blob/8f5212d52b533cdf9d6de9c2bd8a3e01e83e8b9d/compiler/compile/OMRCompilation.hpp#L242) +`performTransformation` is [enabled by option](https://github.com/eclipse-omr/omr/blob/8f5212d52b533cdf9d6de9c2bd8a3e01e83e8b9d/compiler/compile/OMRCompilation.hpp#L242) `TR_TraceOptDetails` or `TR_CountOptTransformations`. `TR_TraceOptDetails` is enabled if the `optDetails` option is specified or if `TR_TraceAll` (`traceFull`) is set. `TR_CountOptTransformations` is enabled normally when the verbose log is enabled or @@ -231,8 +231,8 @@ compilations to avoid overhead in the overwhelmingly common non-tracing case. `performTransformation` is controlled by comparing the current `optIndex` with `firstOptIndex` and `lastOptIndex` options, either when -[it is invoked](https://github.com/eclipse/omr/blob/f5a790b68037be3a48b6e5c4f7e8ae6ad3e30f00/compiler/ras/Debug.cpp#L477) -or in the higher level [performOptimization](https://github.com/eclipse/omr/blob/8f5212d52b533cdf9d6de9c2bd8a3e01e83e8b9d/compiler/optimizer/OMROptimizer.cpp#L1670-L1671) +[it is invoked](https://github.com/eclipse-omr/omr/blob/f5a790b68037be3a48b6e5c4f7e8ae6ad3e30f00/compiler/ras/Debug.cpp#L477) +or in the higher level [performOptimization](https://github.com/eclipse-omr/omr/blob/8f5212d52b533cdf9d6de9c2bd8a3e01e83e8b9d/compiler/optimizer/OMROptimizer.cpp#L1670-L1671) if the optimization is not set as `MustBeDone`. `lastOptIndex` - the index of the last optimization - can be used to narrow things @@ -405,7 +405,7 @@ table below lists a few commonly used ones: | traceOptTrees | Dump trees after each optimization. | | traceTrees | Dump trees after each compilation phase. | -To see the complete set of trace options, see the [logging options listed in OMROptions.cpp](https://github.com/eclipse/omr/blob/e2f65411e67d21ef04e2062a8945e604d82cb19e/compiler/control/OMROptions.cpp#L1118). +To see the complete set of trace options, see the [logging options listed in OMROptions.cpp](https://github.com/eclipse-omr/omr/blob/e2f65411e67d21ef04e2062a8945e604d82cb19e/compiler/control/OMROptions.cpp#L1118). ### Filtering methods diff --git a/doc/compiler/extensible_classes/Extensible_Classes.md b/doc/compiler/extensible_classes/Extensible_Classes.md index 713e1ad75b..3327ec0dcf 100644 --- a/doc/compiler/extensible_classes/Extensible_Classes.md +++ b/doc/compiler/extensible_classes/Extensible_Classes.md @@ -10,7 +10,7 @@ is available at https://www.apache.org/licenses/LICENSE-2.0. This Source Code may also be made available under the following Secondary Licenses when the conditions for such availability set forth in the Eclipse Public License, v. 2.0 are satisfied: GNU -General Public License, version 2 with the GNU Classpath +General Public License, version 2 with the GNU Classpath Exception [1] and GNU General Public License, version 2 with the OpenJDK Assembly Exception [2]. @@ -323,4 +323,4 @@ ancestor, it can extend that class using its direct parent's namespace. This can lead to some hard-to-debug issues. More details about namespace aliases and the debate about their usage is -tracked in [issue #527 on Github](https://github.com/eclipse/omr/issues/527). +tracked in [issue #527 on Github](https://github.com/eclipse-omr/omr/issues/527). diff --git a/doc/compiler/il/MainlineAndOutOfLineCode.md b/doc/compiler/il/MainlineAndOutOfLineCode.md index d96293e18a..d601031d0e 100644 --- a/doc/compiler/il/MainlineAndOutOfLineCode.md +++ b/doc/compiler/il/MainlineAndOutOfLineCode.md @@ -71,5 +71,5 @@ or `hot`, blocks are kept close. The `OOL` code section is used by codegen to emit slow path instructions so that the register allocator could allocate the registers first for the fast path to minimize the impact of register shuffling or register spilling -on the fast path. More details can be found in [omr/compiler/codegen/OutOfLineCodeSection.hpp](https://github.com/eclipse/omr/blob/2ccbf5e8ce2cc1f7b0888e562ca9ee11e712f5d9/compiler/codegen/OutOfLineCodeSection.hpp#L36-L106) +on the fast path. More details can be found in [omr/compiler/codegen/OutOfLineCodeSection.hpp](https://github.com/eclipse-omr/omr/blob/2ccbf5e8ce2cc1f7b0888e562ca9ee11e712f5d9/compiler/codegen/OutOfLineCodeSection.hpp#L36-L106) diff --git a/doc/compiler/optimizer/DataFlowEngine.md b/doc/compiler/optimizer/DataFlowEngine.md index 839c5a39d9..874410e564 100644 --- a/doc/compiler/optimizer/DataFlowEngine.md +++ b/doc/compiler/optimizer/DataFlowEngine.md @@ -35,31 +35,31 @@ print(z); For a compiler to be able to deduce this on arbitrary programs it must use a data-flow analysis called _reaching definitions_ which for a particular _use_ of a variable at a particular point in the program gives the list of all possible definitions (_def_) of that variable that can reach the particular use. -[ReachingDefinitions.cpp](https://github.com/eclipse/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/ReachingDefinitions.cpp) implements the reaching definitions data-flow analysis. We will use this as an example to explain the virtual hierarchy of classes which drive data-flow analyses. +[ReachingDefinitions.cpp](https://github.com/eclipse-omr/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/ReachingDefinitions.cpp) implements the reaching definitions data-flow analysis. We will use this as an example to explain the virtual hierarchy of classes which drive data-flow analyses. -### [`TR_DataFlowAnalysis`](https://github.com/eclipse/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L98-L223) +### [`TR_DataFlowAnalysis`](https://github.com/eclipse-omr/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L98-L223) The root of the hierarchy that all data-flow analyses start at is `TR_DataFlowAnalysis`. This class contains mostly boilerplate code that aids in memory allocation, access to commonly used data structures, aliasing questions, tracing, and debugging information. This class also provides pure virtual functions which must be implemented by the derived classes. Developers writing new data-flow analyses will typically not be inheriting this class. -### [`TR_BasicDFSetAnalysis`](https://github.com/eclipse/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L225-L359) +### [`TR_BasicDFSetAnalysis`](https://github.com/eclipse-omr/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L225-L359) The `TR_BasicDFSetAnalysis` inherits from `TR_DataFlowAnalysis` and is a templated class representing data-flow analyses which use containers (sets) of bits which are flown around the program during the analysis. The set is represented by the template parameter `T` and it can be either a `TR_BitVector` or bit set (for example `TR_SingleBitContainer`). -There is only one other class which inherits from `TR_DataFlowAnalysis` and that does not user bit containers as the underlying data structure; it is the [exception check motion](https://github.com/eclipse/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/PartialRedundancy.hpp#L150-L276) data-flow analysis found in the Partial Redundancy optimization. It uses linked lists as the underlying data structure flown around during the data-flow analysis. It is the only non-bit container based data-flow analysis in OMR at the moment. +There is only one other class which inherits from `TR_DataFlowAnalysis` and that does not user bit containers as the underlying data structure; it is the [exception check motion](https://github.com/eclipse-omr/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/PartialRedundancy.hpp#L150-L276) data-flow analysis found in the Partial Redundancy optimization. It uses linked lists as the underlying data structure flown around during the data-flow analysis. It is the only non-bit container based data-flow analysis in OMR at the moment. #### Counting and initialization -The `TR_BasicDFSetAnalysis` contains many virtual functions which subclasses will override. One such example is the [`getNumberOfBits`](https://github.com/eclipse/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L262) API which subclasses will use to initialize the sizes of the sets which will be used in the data-flow equations. It is up to the subclasses to decide how _number of bits_ are counted. For example some times the number of bits depends on the number of symbol references, sometimes the number of certain type of nodes if we are counting loads or stores for example. In case of reaching definitions [`TR_ReachingDefinitions::getNumberOfBits`](https://github.com/eclipse/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/ReachingDefinitions.cpp#L92-L95) returns the total number of definitions seen in the compilation unit. +The `TR_BasicDFSetAnalysis` contains many virtual functions which subclasses will override. One such example is the [`getNumberOfBits`](https://github.com/eclipse-omr/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L262) API which subclasses will use to initialize the sizes of the sets which will be used in the data-flow equations. It is up to the subclasses to decide how _number of bits_ are counted. For example some times the number of bits depends on the number of symbol references, sometimes the number of certain type of nodes if we are counting loads or stores for example. In case of reaching definitions [`TR_ReachingDefinitions::getNumberOfBits`](https://github.com/eclipse-omr/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/ReachingDefinitions.cpp#L92-L95) returns the total number of definitions seen in the compilation unit. -Other pure virtual functions include initialization functions [`initalizeInfo`](https://github.com/eclipse/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L264-L265) and [`inverseInitializeInfo`](https://github.com/eclipse/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L264-L265) which initialize the template container based on the number of bits. These APIs are meant to be implemented by subclasses depending on the type of confluence operation performed which is discussed below. +Other pure virtual functions include initialization functions [`initalizeInfo`](https://github.com/eclipse-omr/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L264-L265) and [`inverseInitializeInfo`](https://github.com/eclipse-omr/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L264-L265) which initialize the template container based on the number of bits. These APIs are meant to be implemented by subclasses depending on the type of confluence operation performed which is discussed below. #### Union & intersection confluence operators In literature, data-flow analyses are often expressed in terms of data-flow equations which give us a blueprint for how to compose information as we traverse the CFG. These operations are called confluence operators and when dealing with bit sets they often map to set operations such as set union, intersection, and difference. -Intuitively set _union_ confluence operations aggregate data as we traverse the CFG. The bit sets start off with all bits cleared and we add information as the data-flow engine traverses the CFG. Reaching definitions is an example of a set union data-flow analysis, since we want to discover the minimal set of definitions which may reach a particular use. On the other hand, set _intersection_ confluence operations refine data as we traverse the CFG. The bit sets start off with all bits set and we remove information as the data-flow engine traverses the CFG. [Delaydness](https://github.com/eclipse/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/Delayedness.cpp#L39-L50) is an example of a set intersection data-flow analysis found in PRE. +Intuitively set _union_ confluence operations aggregate data as we traverse the CFG. The bit sets start off with all bits cleared and we add information as the data-flow engine traverses the CFG. Reaching definitions is an example of a set union data-flow analysis, since we want to discover the minimal set of definitions which may reach a particular use. On the other hand, set _intersection_ confluence operations refine data as we traverse the CFG. The bit sets start off with all bits set and we remove information as the data-flow engine traverses the CFG. [Delaydness](https://github.com/eclipse-omr/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/Delayedness.cpp#L39-L50) is an example of a set intersection data-flow analysis found in PRE. -In OMR the confluence operation is implemented via a function call to APIs defined within the `TR_BasicDFSetAnalysis` class; the [`compose`](https://github.com/eclipse/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L266-L267) and [`inverseCompose`](https://github.com/eclipse/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L266-L267) APIs. These APIs are meant to be overriden in subclasses and may have different implementations depending on what our confluence operator is (union vs. intersection). The `inverseCompose` API is, as the name suggests, the inverse operation of the `compose`. So if union is the `compose` confluence operator, then intersection would be the `inverseCompose` operation. +In OMR the confluence operation is implemented via a function call to APIs defined within the `TR_BasicDFSetAnalysis` class; the [`compose`](https://github.com/eclipse-omr/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L266-L267) and [`inverseCompose`](https://github.com/eclipse-omr/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L266-L267) APIs. These APIs are meant to be overriden in subclasses and may have different implementations depending on what our confluence operator is (union vs. intersection). The `inverseCompose` API is, as the name suggests, the inverse operation of the `compose`. So if union is the `compose` confluence operator, then intersection would be the `inverseCompose` operation. #### Support for _gen_ and _kill_ sets @@ -67,21 +67,21 @@ In literature, data-flow equations are typically expressed in terms of _in_, _ou For reaching definitions the _gen_ set would represent the set of variable definitions that appear within a program fragment reach the end of the program fragment. The _kill_ set would represent the set of all definitions that never reach the end of the program fragment. -The _program fragment_ in OMR can be as small as an individual treetop or as large as a _region_ which could be a collection of basic blocks. The notion of whether a data-flow analysis supports _gen_ and _kill_ sets is expressed via the [`supportsGenAndKillSets`](https://github.com/eclipse/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L260) API which is meant to be overridden by the subclasses. For analyses which return true for this query, the data-flow engine will be setup to operate on _gen_ and _kill_ sets which are represented by the template parameter and operate on a larger program fragment known as a _region_ (see [Operation on Structures and Regions](#Operation-on-Structures-and-Regions) section). This is mostly an internal caching mechanism to improve compile time performance of computationally expensive data-flow analyses. +The _program fragment_ in OMR can be as small as an individual treetop or as large as a _region_ which could be a collection of basic blocks. The notion of whether a data-flow analysis supports _gen_ and _kill_ sets is expressed via the [`supportsGenAndKillSets`](https://github.com/eclipse-omr/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L260) API which is meant to be overridden by the subclasses. For analyses which return true for this query, the data-flow engine will be setup to operate on _gen_ and _kill_ sets which are represented by the template parameter and operate on a larger program fragment known as a _region_ (see [Operation on Structures and Regions](#Operation-on-Structures-and-Regions) section). This is mostly an internal caching mechanism to improve compile time performance of computationally expensive data-flow analyses. What is the alternative? Instead of using _gen_ and _kill_ sets we would walk the treetops and the descending nodes every time. Since data-flow is iterative it can cause us to visit the same block several times while traversing the CFG in order to converge. If we are in a deeply nested loop we may visit the same block many times, so rather than visiting the nodes each and every time we analyze the block we would cache that information in the _gen_ and _kill_ sets for that block and use that to generate the _out_ set for the block. #### Container node number pair -A space saving optimization found within the `TR_BasicDFSetAnalysis` class is the notion of [`TR_ContainerNodeNumberPair`](https://github.com/eclipse/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L286-L296) which encapsulates the notion of multiple _out_ sets for a particular block. We need to represent the solutions to the data-flow equations the successors of a particular block. There are usually only a handful of successors, so rather than allocating a large array of arity equal to the number of blocks to hold the solution to the data-flow equations, we simply use this pair data structure to represent a linked list of solutions to the successors. +A space saving optimization found within the `TR_BasicDFSetAnalysis` class is the notion of [`TR_ContainerNodeNumberPair`](https://github.com/eclipse-omr/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L286-L296) which encapsulates the notion of multiple _out_ sets for a particular block. We need to represent the solutions to the data-flow equations the successors of a particular block. There are usually only a handful of successors, so rather than allocating a large array of arity equal to the number of blocks to hold the solution to the data-flow equations, we simply use this pair data structure to represent a linked list of solutions to the successors. -### [`TR_ForwardDFSetAnalysis`](https://github.com/eclipse/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L362-L411) and [`TR_BackwardDFSetAnalysis`](https://github.com/eclipse/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L506-L553) +### [`TR_ForwardDFSetAnalysis`](https://github.com/eclipse-omr/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L362-L411) and [`TR_BackwardDFSetAnalysis`](https://github.com/eclipse-omr/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L506-L553) Moving down into the hierarchy the `TR_ForwardDFSetAnalysis` and `TR_BackwardDFSetAnalysis` classes inherit from `TR_BasicDFSetAnalysis` and represent the orientation in which the traversal of the CFG is to be performed by the data-flow engine. These two classes implement the core of the engine which determines which program fragment will be examined next and supplies additional virtual functions which can be overridden by the subclasses. -A fairly concise example of what type of functionality these classes provide can be found in the [`analyzeBlockStructure`](https://github.com/eclipse/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/BitVectorAnalysis.cpp#L1385-L1413) implementation. This API is called by the `TR_Structure` object to perform data-flow analysis for a structure containing a single block. We can clearly see how in the forward data-flow analysis case we query the successors of the block and we use the node number container pairs to look for the precomputed _out_ sets which we aggregate. +A fairly concise example of what type of functionality these classes provide can be found in the [`analyzeBlockStructure`](https://github.com/eclipse-omr/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/BitVectorAnalysis.cpp#L1385-L1413) implementation. This API is called by the `TR_Structure` object to perform data-flow analysis for a structure containing a single block. We can clearly see how in the forward data-flow analysis case we query the successors of the block and we use the node number container pairs to look for the precomputed _out_ sets which we aggregate. -### [`TR_UnionDFSetAnalysis`](https://github.com/eclipse/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L445-L462) and [`TR_IntersectionDFSetAnalysis`](https://github.com/eclipse/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L413-L443) +### [`TR_UnionDFSetAnalysis`](https://github.com/eclipse-omr/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L445-L462) and [`TR_IntersectionDFSetAnalysis`](https://github.com/eclipse-omr/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L413-L443) There are actually four classes within this category: @@ -92,15 +92,15 @@ The former two represent forward analysis while the latter two represent backwar The implementation of these classes are quite trivial as the set union and intersection operations are implemented within the container classes. Never the less they are an important piece of the virtual hierarchy before we reach the leaf classes. -Reaching definitions is an example of a forward union set data-flow analysis while [liveness](https://github.com/eclipse/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L840-L871) is an example of a backward union set data-flow analysis. +Reaching definitions is an example of a forward union set data-flow analysis while [liveness](https://github.com/eclipse-omr/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L840-L871) is an example of a backward union set data-flow analysis. ### Leaf Classes -The final step in the virtual hierarchy are the leaf classes, which typically map to textbook examples of data-flow analyses. [`TR_ReachingDefinitions`](https://github.com/eclipse/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L480-L504) and [`TR_Liveness`](https://github.com/eclipse/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L840-L871) are two examples of leaf classes. By the time we reach the leaf classes, many of the virtual functions have already been implemented for us by the super classes. You may note that there isn't a lot of code in these leaf classes. This is a good thing, and it means the APIs in the virtual hierarchy have implemented most of the functionality for us, and we as developers are only left with modeling some specifics about our particular data-flow analysis, such as initialization and counting. +The final step in the virtual hierarchy are the leaf classes, which typically map to textbook examples of data-flow analyses. [`TR_ReachingDefinitions`](https://github.com/eclipse-omr/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L480-L504) and [`TR_Liveness`](https://github.com/eclipse-omr/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/DataFlowAnalysis.hpp#L840-L871) are two examples of leaf classes. By the time we reach the leaf classes, many of the virtual functions have already been implemented for us by the super classes. You may note that there isn't a lot of code in these leaf classes. This is a good thing, and it means the APIs in the virtual hierarchy have implemented most of the functionality for us, and we as developers are only left with modeling some specifics about our particular data-flow analysis, such as initialization and counting. ## Operation on Structures and Regions -As previously discussed, _gen_ and _kill_ sets are typically thought of in terms of basic blocks, however in the OMR data-flow engine they are thought of in terms of [`TR_Structure`](https://github.com/eclipse/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/Structure.hpp#L58-L257). This design decision was made to give us the freedom to be able to generate _gen_ and _kill_ sets not just on a black basis but in terms of larger program fragments which improves performance of the OMR compiler when used in JIT compilation environments. +As previously discussed, _gen_ and _kill_ sets are typically thought of in terms of basic blocks, however in the OMR data-flow engine they are thought of in terms of [`TR_Structure`](https://github.com/eclipse-omr/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/Structure.hpp#L58-L257). This design decision was made to give us the freedom to be able to generate _gen_ and _kill_ sets not just on a black basis but in terms of larger program fragments which improves performance of the OMR compiler when used in JIT compilation environments. A `TR_Structure` is composed one or more: @@ -125,7 +125,7 @@ Some data-flow analyses may get disinterested in using _gen_ and _kill_ sets for In general using structures as our program fragments enables us to save roughly 10% compile time performance during data-flow analyses. -## [OMRDataFlowAnalysis.enum](https://github.com/eclipse/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/OMRDataFlowAnalysis.enum) +## [OMRDataFlowAnalysis.enum](https://github.com/eclipse-omr/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/OMRDataFlowAnalysis.enum) The (mostly up-to-date) list of all data-flow analyses classes supported in OMR are listed in this file. This file can be used as an extension point to add new data-flow analysis in downstream projects consuming OMR. @@ -143,8 +143,8 @@ If the block does not change `x` or `y`, `x+y` can be moved pass this block. If and `x` and `y` have not been changed in between, the two computations can be commoned by Partial Redundancy Elimination (PRE). The value of `x+y` can be stored in a temporary which can be used in later blocks instead of computing `x+y` again. -[TR_LocalTransparency](https://github.com/eclipse/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/LocalAnalysis.hpp#L230) -runs before [TR_LocalAnticipatability](https://github.com/eclipse/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/LocalAnalysis.hpp#L286): +[TR_LocalTransparency](https://github.com/eclipse-omr/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/LocalAnalysis.hpp#L230) +runs before [TR_LocalAnticipatability](https://github.com/eclipse-omr/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/LocalAnalysis.hpp#L286): - `TR_LocalTransparency::_transparencyInfo[symRefNum]`: A bit vector indicates which expressions (identified by local index) will not be affected by the sym ref if the sym ref is changed in the block - `TR_LocalTransparency::_info[blockNum]._analysisInfo`: A bit vector indicates whether or not the expression (identified by local index) @@ -158,8 +158,8 @@ anticipatable in a block, the expression is computed in the block and can be mov expression. For example, if `x+y` is computed in `block_10`, the expression `x+y` can be a candidate of being locally anticipatable in `block_10`. If `x+y` is not computed in `block_10`, the expression `x+y` will not be in the Local Anticipatablility set. -[TR_LocalAnticipatability](https://github.com/eclipse/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/LocalAnalysis.hpp#L286) -runs after [TR_LocalTransparency](https://github.com/eclipse/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/LocalAnalysis.hpp#L230) +[TR_LocalAnticipatability](https://github.com/eclipse-omr/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/LocalAnalysis.hpp#L286) +runs after [TR_LocalTransparency](https://github.com/eclipse-omr/omr/blob/f2bc4f8f6eb09f6cc8fc4ba48717de4880b970e3/compiler/optimizer/LocalAnalysis.hpp#L230) - `TR_LocalAnticipatability::_info[blockNum]._analysisInfo`: A bit vector indicates whether or not the value of an expression (identified by local index) would be changed if it were computed at the very start of the block (upward anticipatable notion) - `TR_LocalAnticipatability::_info[blockNum]._downwardExposedAnalysisInfo`: A bit vector indicates whether or not the value of an diff --git a/doc/compiler/optimizer/Inliner.md b/doc/compiler/optimizer/Inliner.md index 696c059c20..31f1125bc6 100644 --- a/doc/compiler/optimizer/Inliner.md +++ b/doc/compiler/optimizer/Inliner.md @@ -10,7 +10,7 @@ is available at https://www.apache.org/licenses/LICENSE-2.0. This Source Code may also be made available under the following Secondary Licenses when the conditions for such availability set forth in the Eclipse Public License, v. 2.0 are satisfied: GNU -General Public License, version 2 with the GNU Classpath +General Public License, version 2 with the GNU Classpath Exception [1] and GNU General Public License, version 2 with the OpenJDK Assembly Exception [2]. @@ -23,32 +23,32 @@ SPDX-License-Identifier: EPL-2.0 OR Apache-2.0 OR GPL-2.0-only WITH Classpath-ex ## Overview Inliner in OMR is both -* An *optimization* that could be run multiple times as a part an optimization strategy defined in [OMROptimizer.cpp](https://github.com/eclipse/omr/blob/master/compiler/optimizer/OMROptimizer.cpp) -* An *API* other optimizations (e.g. [GlobalValuePropagation](https://github.com/eclipse/omr/blob/master/compiler/optimizer/ValuePropagation.cpp), EscapeAnalysis) could use in order to inline calls in IL. +* An *optimization* that could be run multiple times as a part an optimization strategy defined in [OMROptimizer.cpp](https://github.com/eclipse-omr/omr/blob/master/compiler/optimizer/OMROptimizer.cpp) +* An *API* other optimizations (e.g. [GlobalValuePropagation](https://github.com/eclipse-omr/omr/blob/master/compiler/optimizer/ValuePropagation.cpp), EscapeAnalysis) could use in order to inline calls in IL. * A host of smaller optimizations that are either *convenient* to run as the part of inlining or *beneficial* to the inlining process itself. These optimizations can * Reduce the number of temporaries used to pass arguments from a *caller* to a *callee* - * Propagate *type* information along edges of a call graph. The type information can in turn be used in many different ways including **devirtualization** (resolving a polymorphic call to a particular implementation) or field chain folding - + * Propagate *type* information along edges of a call graph. The type information can in turn be used in many different ways including **devirtualization** (resolving a polymorphic call to a particular implementation) or field chain folding + ## Higher-Level Structure -In order to serve as a standalone optimization, Inliner includes a class called `TR_TrivialInliner` which extends `TR::Optimization` and implements `perform` and `create` methods, so Optimizer knows how to instantiate and invoke Inliner. `TR_TrivialInliner` is a very lightweight class whose sole job is to create an instance of `TR_DumbInliner` and call its `performInlining`. You might want to think of `TR_DumbInliner` as a *"real"* Inliner and of `TR_TrivialInliner` as an adapter class that needs to conform to the contract defined by Optimizer infrastructure. +In order to serve as a standalone optimization, Inliner includes a class called `TR_TrivialInliner` which extends `TR::Optimization` and implements `perform` and `create` methods, so Optimizer knows how to instantiate and invoke Inliner. `TR_TrivialInliner` is a very lightweight class whose sole job is to create an instance of `TR_DumbInliner` and call its `performInlining`. You might want to think of `TR_DumbInliner` as a *"real"* Inliner and of `TR_TrivialInliner` as an adapter class that needs to conform to the contract defined by Optimizer infrastructure. This is a class hierarchy of the adapter class * **TR::Optimization** * **TR_TrivialInliner** -This is a class hierarchy of the *real* Inliner +This is a class hierarchy of the *real* Inliner * **TR_InlinerBase** * **TR_DumbInliner** * **TR_InlineCall** - * **TR_MultipleTargetInliner** - - + * **TR_MultipleTargetInliner** + + * **TR_InlinerBase** is a parent class containing common functionality used by all of its children (e.g. TR_DumbInliner, TR_InlineCall, etc) -* **TR_DumbInliner** is a simple greedy Inliner. Given a starting budget **initialSize**, **TR_DumbInliner** walks the IL trees and inlines calls in the order they appear in IL until it squandres its entire budget. A callee receives the budget adjusted by the sizes of every caller in a call chain from the topmost caller to that particular callee. -* **TR_InlineCall** is an API other optimizations could use to inline a particular call in IL. **TR_InlineCall** uses very similar heuristics to **TR_DumbInliner**. The budget is typically smaller than **TR_DumbInliner** +* **TR_DumbInliner** is a simple greedy Inliner. Given a starting budget **initialSize**, **TR_DumbInliner** walks the IL trees and inlines calls in the order they appear in IL until it squandres its entire budget. A callee receives the budget adjusted by the sizes of every caller in a call chain from the topmost caller to that particular callee. +* **TR_InlineCall** is an API other optimizations could use to inline a particular call in IL. **TR_InlineCall** uses very similar heuristics to **TR_DumbInliner**. The budget is typically smaller than **TR_DumbInliner** ### **TR_CallSite**s & **TR_CallTarget**s @@ -56,19 +56,19 @@ There are two more very important classes in Inliner: * **TR_CallSite** * **TR_CallTarget** - -**TR_CallSite** includes all the information relevant to a particular call encountered in IL. For example, - * `callNode` -- an original callNode containing a call + +**TR_CallSite** includes all the information relevant to a particular call encountered in IL. For example, + * `callNode` -- an original callNode containing a call * `callNodeTreeTop`, -- an TR::TreeTop containing the `callNode` - * `initialCalleeMethod`, -- an initial callee method. - + * `initialCalleeMethod`, -- an initial callee method. + are all properties of **TR_CallSite** - -Note, `initialCalleeMethod` will not necessarily be the method Inliner chooses to inline. This is especially true for *polymorphic* calls where there is more than one choice due to multiple receivers and/or receiver types. Inliner represents this possible set of choices by **TR_CallTarget**s - -**TR_CallTarget** directly corresponds to one of the possible implementations of a particular **TR_CallSite**. As such, it typically includes the exact `TR_ResolvedMethod` and `TR_ResolvedMethodSymbol`. It also includes a `TR_VirtualGuardSelection` object that describes testing conditions Inliner needs to generate to make sure that it is valid ("validitity" here could mean different things depending on a type of **TR_CallSite**) to execute the inlined body for the implementation it has chosen to inline. -### Inlining Guards +Note, `initialCalleeMethod` will not necessarily be the method Inliner chooses to inline. This is especially true for *polymorphic* calls where there is more than one choice due to multiple receivers and/or receiver types. Inliner represents this possible set of choices by **TR_CallTarget**s + +**TR_CallTarget** directly corresponds to one of the possible implementations of a particular **TR_CallSite**. As such, it typically includes the exact `TR_ResolvedMethod` and `TR_ResolvedMethodSymbol`. It also includes a `TR_VirtualGuardSelection` object that describes testing conditions Inliner needs to generate to make sure that it is valid ("validitity" here could mean different things depending on a type of **TR_CallSite**) to execute the inlined body for the implementation it has chosen to inline. + +### Inlining Guards Guards are a very *important* tool available to Inliner, so let's take a look at an example where Inliner needs to use a inline guard. @@ -84,27 +84,27 @@ class A { class B extends A { @override int method1() { return 1; } - + static int callMethod1 (A a) { return a.method1(); } - + } -``` +``` -Now let's assume that callMethod1 receives objects of type **A** in 90% of all calls to `callMethod1` and the rest could be objects of type **B** or of any other type that might extend **A**. If Inliner wants to inline a virtual call `a.method1();` it needs to consult a Profiler in this case to get a list of receiver types recorded (seen) at this particular callsite. The Profiler provides Inliner with this same statistics `{ type.A : 0.9, type.B : 0.1 }`. Based on the statistics Inliner creates two **TR_CallTargets** -- one for `A.method1` and another one for `B.method1` -- to represent the possible set of the choices. Each **TR_CallTarget** points to its own **TR_VirtualGuardSelection** (briefly mentioned above). **TR_VirtualGuardSelection** contains two very important fields: **_type** and **_kind** that Inliner uses to generate the testing conditions. In the example given, `_kind` would be set to **TR_ProfiledGuard** and `_type` would be equal to **TR_VftTest**. In other words, this means that Inliner needs to generate a *class* test before the inlined body should it decide to inline either `A.method1` or `B.method1`. The class test is one of the two profiled tests: **TR_VftTest** and **TR_MethodTest**, available in OMR. +Now let's assume that callMethod1 receives objects of type **A** in 90% of all calls to `callMethod1` and the rest could be objects of type **B** or of any other type that might extend **A**. If Inliner wants to inline a virtual call `a.method1();` it needs to consult a Profiler in this case to get a list of receiver types recorded (seen) at this particular callsite. The Profiler provides Inliner with this same statistics `{ type.A : 0.9, type.B : 0.1 }`. Based on the statistics Inliner creates two **TR_CallTargets** -- one for `A.method1` and another one for `B.method1` -- to represent the possible set of the choices. Each **TR_CallTarget** points to its own **TR_VirtualGuardSelection** (briefly mentioned above). **TR_VirtualGuardSelection** contains two very important fields: **_type** and **_kind** that Inliner uses to generate the testing conditions. In the example given, `_kind` would be set to **TR_ProfiledGuard** and `_type` would be equal to **TR_VftTest**. In other words, this means that Inliner needs to generate a *class* test before the inlined body should it decide to inline either `A.method1` or `B.method1`. The class test is one of the two profiled tests: **TR_VftTest** and **TR_MethodTest**, available in OMR. Now Inliner decides to inline `A.method1` (`A`'s implementation of `method1`). It generates the IL similar to the pseudo IL below. ```cpp BB_Start NULLCHK - aloadi + aloadi aload ifacmpne --> - ==> aloadi + ==> aloadi aconst A.vft BB_Start istore @@ -120,29 +120,29 @@ istore goto ``` -Below is a graphical representation of the same process. +Below is a graphical representation of the same process. + +`` is transformed -`` is transformed - ``` - +--------------+ - | | - | BB_Start <1> | - | | - |IL before call| - | | - | ... | - | | - | method1() | - | | - | ... | + +--------------+ + | | + | BB_Start <1> | + | | + |IL before call| + | | + | ... | + | | + | method1() | + | | + | ... | | | |IL after call | +--------------+ -``` - -into the following +``` + +into the following ``` @@ -162,22 +162,22 @@ into the following | aconst | | | | | +---------------+ | - v | - +---------------+ | - | | | - |BB_Start <2> | | - |============== | | - |store tmp3 | | - | aload arg1 | | - |store tmp4 | | - | aload arg2 | | - | | | - | method1 IL | | - +---------------+ | - v | - +----------------+ | - | | | - +> | BB_Start <4> | | + v | + +---------------+ | + | | | + |BB_Start <2> | | + |============== | | + |store tmp3 | | + | aload arg1 | | + |store tmp4 | | + | aload arg2 | | + | | | + | method1 IL | | + +---------------+ | + v | + +----------------+ | + | | | + +> | BB_Start <4> | | | | ============== | | | | aload tmp1 | | | | aload tmp2 | | @@ -208,18 +208,18 @@ into the following ``` -* In `` Inliner first needs to load the vft pointer (virtual function table) out of an object. This pointer is used in OMR to uniquely identify a particular class. +* In `` Inliner first needs to load the vft pointer (virtual function table) out of an object. This pointer is used in OMR to uniquely identify a particular class. * Next, `ifacmpne` compares the runtime type of an object against `A.vft` since this is the class containing the inlined implementation (`A.method1`) - * If the test fails, the execution transfers to `` and we make a virtual call. This virtual call is resolved by runtime depending on the current type of `a`. The result of the call is stored into ``. Think of `` as a temporary variable created by Inliner so it could be use it across block boundaries. Remember, OMR does *not* allow us to use commoned expressions across blocks. - * If the test succeeds, we execute the body of `A` which also stores `iconst 0` into ``. -* Lastly, we return the value stored in `` which either comes from `` or `` + * If the test fails, the execution transfers to `` and we make a virtual call. This virtual call is resolved by runtime depending on the current type of `a`. The result of the call is stored into ``. Think of `` as a temporary variable created by Inliner so it could be use it across block boundaries. Remember, OMR does *not* allow us to use commoned expressions across blocks. + * If the test succeeds, we execute the body of `A` which also stores `iconst 0` into ``. +* Lastly, we return the value stored in `` which either comes from `` or `` Note, `` is typically called a *merge* block due to the fact that the control flow merges back from either inlined callee's body or from the block containing virtual call (``) ## Main phases of Inlining ``` -performInlining --> inlineCallTargets --> inlineCallTarget --> inlineCallTarget2 ------------ ... +performInlining --> inlineCallTargets --> inlineCallTarget --> inlineCallTarget2 ------------ ... ^ | |_________[until there's budget left]__________________| @@ -229,15 +229,15 @@ performInlining --> inlineCallTargets --> inlineCallTarget --> inlineCallTarget2 ### inlineCallTargets -`inlineCallTargets` identifies a list of potential callees by walking the IL trees of a passed-in caller symbol and inlines some according to the set policy and budget. +`inlineCallTargets` identifies a list of potential callees by walking the IL trees of a passed-in caller symbol and inlines some according to the set policy and budget. It performs these 3 very important duties: * Adjusting the inliner budget which will be propagated down via `TR_CallStack` to the inlined callees * Deciding whether a basic block containing a call is *cold* in which case the call is typically not inlined unless the current inlining policy `inlineMethodEvenForColdBlocks` says otherwise. -* Calling `analyzeCallSite` to proceed with the current call +* Calling `analyzeCallSite` to proceed with the current call -In turn, `analyzeCallSite` relies on the following methods to do its job. +In turn, `analyzeCallSite` relies on the following methods to do its job. * **analyzeCallSite** * **TR_CallSite::create** @@ -246,16 +246,16 @@ In turn, `analyzeCallSite` relies on the following methods to do its job. * **applyPolicyToTargets** * inlineCallTarget -`analyzeCallSite` calls `TR_CallSite::create` to create a TR_CallSite. `TR_CallSite::create` is a static constructor method that analyzes the *type* of the call and returns a `TR_CallSite` instance of a corresponding type. [CallInfo.hpp](https://github.com/eclipse/omr/blob/master/compiler/optimizer/CallInfo.hpp) specifies the list of available `TR_CallSite` types (e.g. `TR_DirectCallSite`, `TR_IndirectCallSite`, etc). The reason behind this type proliferation is to decouple the logic of *finding* and *creating* (packaged in `findCallSiteTarget`) a call target from Inliner code and from different `TR_CallSite` types. In principle, if two types share common functionality they should extend the same parent type. +`analyzeCallSite` calls `TR_CallSite::create` to create a TR_CallSite. `TR_CallSite::create` is a static constructor method that analyzes the *type* of the call and returns a `TR_CallSite` instance of a corresponding type. [CallInfo.hpp](https://github.com/eclipse-omr/omr/blob/master/compiler/optimizer/CallInfo.hpp) specifies the list of available `TR_CallSite` types (e.g. `TR_DirectCallSite`, `TR_IndirectCallSite`, etc). The reason behind this type proliferation is to decouple the logic of *finding* and *creating* (packaged in `findCallSiteTarget`) a call target from Inliner code and from different `TR_CallSite` types. In principle, if two types share common functionality they should extend the same parent type. -Next, `analyzeCallSite` passes a freshly minted `TR_CallSite` to `getSymbolAndFindInlineTargets`. `getSymbolAndFindInlineTargets` calls ` callsite->findCallSiteTarget(callStack, this);` to let the logic specific to the type of this particular `TR_CallSite` to build a list of possible `TR_CallTarget`s. `getSymbolAndFindInlineTargets`also calls `applyPolicyToTargets` to filter out the list of calltargets depending on an inlining policy. This *policing* occurs both in `applyPolicyToTargets` and also in `getSymbolAndFindInlineTargets`. The policies using `TR_ResolvedMethod` are typically placed in `applyPolicyToTargets` whereas the policies using `TR_ResolvedMethodSymbol` usually go into `getSymbolAndFindInlineTargets`. This is more of a historical idiosyncrasy . It stems from the fact that **TR_MultipleTargetInliner** (not available just yet) uses original bytecodes (as opposed to IL used by `TR_DumbInliner`) to build a call graph. As a result, `TR_ResolvedMethodSymbol`s are not available at that particular stage and `applyPolicyToTargets` is used to apply the inlining policy. +Next, `analyzeCallSite` passes a freshly minted `TR_CallSite` to `getSymbolAndFindInlineTargets`. `getSymbolAndFindInlineTargets` calls ` callsite->findCallSiteTarget(callStack, this);` to let the logic specific to the type of this particular `TR_CallSite` to build a list of possible `TR_CallTarget`s. `getSymbolAndFindInlineTargets`also calls `applyPolicyToTargets` to filter out the list of calltargets depending on an inlining policy. This *policing* occurs both in `applyPolicyToTargets` and also in `getSymbolAndFindInlineTargets`. The policies using `TR_ResolvedMethod` are typically placed in `applyPolicyToTargets` whereas the policies using `TR_ResolvedMethodSymbol` usually go into `getSymbolAndFindInlineTargets`. This is more of a historical idiosyncrasy . It stems from the fact that **TR_MultipleTargetInliner** (not available just yet) uses original bytecodes (as opposed to IL used by `TR_DumbInliner`) to build a call graph. As a result, `TR_ResolvedMethodSymbol`s are not available at that particular stage and `applyPolicyToTargets` is used to apply the inlining policy. Lastly, if all is well, the calltarget is passed on to `inlineCallTarget`. `inlineCallTarget`'s name is a bit of a misnomer. What it actually does is to apply more heuristics (mostly IL-based) to make a final decision on whether the target will be inlined or not. If `inlineCallTarget` decides to inline the target it calls `inlineCallTarget2` - + ### inlineCallTarget2 -`inlineCallTarget2` contains physical inlining mechanics. In other words, this is a method that does *actual* inlining of the target. *Inlining* is a complex process; there are a number of challenges involved (to be discussed next), so `inlineCallTarget2` makes use of numerous helper functions. These are probably the most important ones. - +`inlineCallTarget2` contains physical inlining mechanics. In other words, this is a method that does *actual* inlining of the target. *Inlining* is a complex process; there are a number of challenges involved (to be discussed next), so `inlineCallTarget2` makes use of numerous helper functions. These are probably the most important ones. + * **tryToGenerateILForMethod** * **inlineCallTargets** * **TR_TransformInlinedFunction::transform** @@ -264,60 +264,60 @@ Lastly, if all is well, the calltarget is passed on to `inlineCallTarget`. `inli First, `inlineCallTarget2` calls `tryToInlineTrivialMethod`. `tryToInlineTrivialMethod` is a part of Inliner imbued with *some* knowledge of a target language. `tryToInlineTrivialMethod` is able to recognize certain *standard-library* methods of the target language and generate the IL for those avoiding the full inlining process of `inlineCallTarget2`. If `tryToInlineTrivialMethod` is successful, `inlineCallTarget2` returns immediately. -Next, `inlineCallTarget2` makes a call to `tryToGenerateILForMethod` to generate callee's IL. Typically, the call is successful and inlining proceeds. +Next, `inlineCallTarget2` makes a call to `tryToGenerateILForMethod` to generate callee's IL. Typically, the call is successful and inlining proceeds. -Now that `inlineCallTarget2` got callee's IL it can *recursively* call `inlineCallTargets` to scout and inline possible calls in the callee. +Now that `inlineCallTarget2` got callee's IL it can *recursively* call `inlineCallTargets` to scout and inline possible calls in the callee. -Then, `inlineCallTarget2` initializes `TR_ParameterToArgumentMapper`. `TR_ParameterToArgumentMapper` as its name suggests needs to map *actual* arguments to formal *parameters*. `TR_ParameterToArgumentMapper` *can* directly reuse some of caller's arguments. Currently, the logic in `TR_ParameterToArgumentMapper` will reuse an incoming argument if -* it is a const, +Then, `inlineCallTarget2` initializes `TR_ParameterToArgumentMapper`. `TR_ParameterToArgumentMapper` as its name suggests needs to map *actual* arguments to formal *parameters*. `TR_ParameterToArgumentMapper` *can* directly reuse some of caller's arguments. Currently, the logic in `TR_ParameterToArgumentMapper` will reuse an incoming argument if +* it is a const, * is is *not* modified by callee, -* the argument is *not* used anywhere else, +* the argument is *not* used anywhere else, * the argument is a *this* object and it is used *only* twice: * to fetch a vft out of *this* object - * to be passed as *this* argument to the call. - -Otherwise, `TR_ParameterToArgumentMapper` either creates a fresh temporary to hold the argument value or reuses one of the available temps (see [Temp Sharing](#temp-sharing)) + * to be passed as *this* argument to the call. + +Otherwise, `TR_ParameterToArgumentMapper` either creates a fresh temporary to hold the argument value or reuses one of the available temps (see [Temp Sharing](#temp-sharing)) -`TR_TransformInlinedFunction` object is created and callee's IL transformed in the following ways: +`TR_TransformInlinedFunction` object is created and callee's IL transformed in the following ways: * replaces the uses of callee's parameters with the temps or args assigned by `TR_ParameterToArgumentMapper` via `transformNode` - * transforms callee's return node by + * transforms callee's return node by * creating a new temporary and storing the return value into the temp - * replacing the result of the call (the use of the call node) in caller with the return value - * ignoring the return value if the result of the call is not used. + * replacing the result of the call (the use of the call node) in caller with the return value + * ignoring the return value if the result of the call is not used. After that, `inlineCallTarget2` embeds callee's IL into caller's. The IL includes all the stores required to move arguments into temporaries. Also, Inliner adds CFG callee's CFG (control flow graph) nodes to the caller's CFG. -Next, if `TR_VirtualGuardSelection` of the calltarget dictates that an inlining guard is required for this call, Inliner invokes `addGuardForVirtual`. `addGuardForVirtual` adds a virtual snippet block and generates a configuration described in [Inline Guards](#inlining-guards). `addGuardForVirtual` uses `createVirtualGuard` to generate IL for the guard test (e.g. `ifacmpne`, `ificmpne`, etc). In general, OMR Inliner currently supports only single-condition guards. However, certain guard types (**HCR Guards**) can be combined (merged) and stand for more complicated tests than expressed in IL. +Next, if `TR_VirtualGuardSelection` of the calltarget dictates that an inlining guard is required for this call, Inliner invokes `addGuardForVirtual`. `addGuardForVirtual` adds a virtual snippet block and generates a configuration described in [Inline Guards](#inlining-guards). `addGuardForVirtual` uses `createVirtualGuard` to generate IL for the guard test (e.g. `ifacmpne`, `ificmpne`, etc). In general, OMR Inliner currently supports only single-condition guards. However, certain guard types (**HCR Guards**) can be combined (merged) and stand for more complicated tests than expressed in IL. -We already know that commoned expressions (e.g. nodes with reference counts greater than 1) *can not* span multiple extended basic blocks. A quick refresher, an **extended basic block** (or **superblock**) is a sequence of IL which has an exactly one entry point and *can* have multiple exits. The entry point needs to be the first treetop in the sequence. Unfortunately, Inliner often breaks this rule; it might need to generate an inlining guard or callee itself might introduce extra control flow (e.g. `ifs`, `loops`, etc). If the block containing calls needs to be split into multiple, Inliner needs to identify all the commoned expressions that will end up on the opposite side of the split and fix those. Consider a canonical example where Inliner needs to generate a virtual guard snippet. We saw, in [Inline Guards](#inlining-guards), that the block containing a call (e.g. `method1`) was split at the treetop containing the call node exactly. Now let's imagine that there was a load of some variable right before the call and the very same load node of that variable is used (referenced) again right after the call. The use of the load node after the call (in the merge block) is now invalid and needs to be fixed. +We already know that commoned expressions (e.g. nodes with reference counts greater than 1) *can not* span multiple extended basic blocks. A quick refresher, an **extended basic block** (or **superblock**) is a sequence of IL which has an exactly one entry point and *can* have multiple exits. The entry point needs to be the first treetop in the sequence. Unfortunately, Inliner often breaks this rule; it might need to generate an inlining guard or callee itself might introduce extra control flow (e.g. `ifs`, `loops`, etc). If the block containing calls needs to be split into multiple, Inliner needs to identify all the commoned expressions that will end up on the opposite side of the split and fix those. Consider a canonical example where Inliner needs to generate a virtual guard snippet. We saw, in [Inline Guards](#inlining-guards), that the block containing a call (e.g. `method1`) was split at the treetop containing the call node exactly. Now let's imagine that there was a load of some variable right before the call and the very same load node of that variable is used (referenced) again right after the call. The use of the load node after the call (in the merge block) is now invalid and needs to be fixed. This is precisely the job of `TR_HandleInjectedBasicBlock::findAndReplaceReferences`. `findAndReplaceReferences` calls `collectNodesWithMultipleReferences` to walk the beginning of the extended basic block containing the call up to the last basic block containg the call and collect nodes *whose reference count is greater than 1*. Every time it process such a node it also decrements its `_referencesToBeFound`. If `_referencesToBeFound` of the node comes down to exactly 0 it means that there are no outstanding uses of the node beyond the basic block containing the call and the node does *not* need to be fixed. At this point, the node is removed from `_multiplyReferencedNodes` -If `_multiplyReferencedNodes` does contain the nodes spanning multiple blocks, `findAndReplaceReferences` +If `_multiplyReferencedNodes` does contain the nodes spanning multiple blocks, `findAndReplaceReferences` * calls `createTemps` to store the nodes on `_multiplyReferencedNodes` into temporaries * calls `replaceNodesReferencedFromAbove` to replace the invalid uses in `nextBBEndInCaller` (replaceBlock1) block and `virtualCallSnippet` (replaceBlock2) - -If `virtualCallSnippet` exists (e.g. not equal to `nullptr`) findAndReplaceReferences repeats the entire process on `virtualCallSnippet` to make sure that no commoned nodes created for `virtualCallSnippet` are used in the merge block. + +If `virtualCallSnippet` exists (e.g. not equal to `nullptr`) findAndReplaceReferences repeats the entire process on `virtualCallSnippet` to make sure that no commoned nodes created for `virtualCallSnippet` are used in the merge block. Then, Inliner marks callee's local variables and temproraries created for passing arguments for the caller to the callee as available for *reuse* (Please see [Temp Sharing](#temp-sharing) for more details.) -The very last thing Inliner needs to do is to update caller's flags depending on the inlined callee. `updateCallersFlags` takes care of this task. +The very last thing Inliner needs to do is to update caller's flags depending on the inlined callee. `updateCallersFlags` takes care of this task. ## Additional Topics -### Rematerialization +### Rematerialization @TODO - -### Type Information Propagation + +### Type Information Propagation @TODO -### Temp Sharing +### Temp Sharing @TODO - + diff --git a/doc/compiler/optimizer/IntroLoopOptimizations.md b/doc/compiler/optimizer/IntroLoopOptimizations.md index 04ba4f63f2..50368870c4 100644 --- a/doc/compiler/optimizer/IntroLoopOptimizations.md +++ b/doc/compiler/optimizer/IntroLoopOptimizations.md @@ -79,7 +79,7 @@ if (i< 15) { } ``` If it is a while-do loop, we hoist the first “if” test that controls whether we enter the loop outside the loop. If it is -true, we fall into the loop preheader block and then execute the body of the loop. We will [clone that condition](https://github.com/eclipse/omr/blob/ef9fafc24998865bc4041ad56cc17b2b4c1f210c/compiler/optimizer/LoopCanonicalizer.cpp#L817-L845) +true, we fall into the loop preheader block and then execute the body of the loop. We will [clone that condition](https://github.com/eclipse-omr/omr/blob/ef9fafc24998865bc4041ad56cc17b2b4c1f210c/compiler/optimizer/LoopCanonicalizer.cpp#L817-L845) so that we check it at the end of the loop as well. This is how a while-do loop is converted into a do-while loop by checking the condition outside the loop. @@ -290,7 +290,7 @@ the slow loop is likely not executed based on the assumption that the original g ## 4. Loop Specializer -[Loop Specializer](https://github.com/eclipse/omr/blob/e3a15a993c8aba80582aa1d6f3071e122acbd4c4/compiler/optimizer/LoopVersioner.hpp#L1061-L1071) +[Loop Specializer](https://github.com/eclipse-omr/omr/blob/e3a15a993c8aba80582aa1d6f3071e122acbd4c4/compiler/optimizer/LoopVersioner.hpp#L1061-L1071) subclasses Loop Versioner and shares about 90% of the code with Loop Versioner. The reason that Loop Specializer shares so much code with Loop Versioner is that the transformation it performs is quite like what Loop Versioner does. @@ -302,7 +302,7 @@ In the following example, `n` is loop invariant. It would be great if we know wh a small value like `10` or `4`, rather than testing if the value is between `0` and `n`, we could test if the value is between `0` and `10`, or whatever the value is profiled as. The loop could be unrolled completely and would be eliminated. Even if the loop cannot be unrolled completely, knowing the precise bounds of the constant allows subsequent optimizations -such as [Value Propagation](https://github.com/eclipse/omr/blob/6cc32df405cd1dd688470e0b5b13fcc5938e2921/doc/compiler/optimizer/ValuePropagation.md) +such as [Value Propagation](https://github.com/eclipse-omr/omr/blob/6cc32df405cd1dd688470e0b5b13fcc5938e2921/doc/compiler/optimizer/ValuePropagation.md) to further constrain expressions within the loop, which may enable further optimization. ``` diff --git a/doc/compiler/optimizer/IntroReadLogFile.md b/doc/compiler/optimizer/IntroReadLogFile.md index ded6fdb8db..9deb59a8cf 100644 --- a/doc/compiler/optimizer/IntroReadLogFile.md +++ b/doc/compiler/optimizer/IntroReadLogFile.md @@ -23,7 +23,7 @@ Wildcard expressions can be used to log multiple methods. For example, `{java/ut method that is compiled in `java/util/hashMap`. `traceFull` turns on all important trace types (i.e. `traceBC`, `traceTrees`, `traceCG`, `traceOptTrees`, and `optDetails`). -Tracing options are defined in [OMROptions.cpp](https://github.com/eclipse/omr/blob/1d8fb435675f022855948c08f08f6db66cbe38d8/compiler/control/OMROptions.cpp#L1136). +Tracing options are defined in [OMROptions.cpp](https://github.com/eclipse-omr/omr/blob/1d8fb435675f022855948c08f08f6db66cbe38d8/compiler/control/OMROptions.cpp#L1136). ## 2. Bytecodes And Trees @@ -83,7 +83,7 @@ Another eye catcher is `“This method is”` that indicates the hotness level. 16, JBifne 13, 29, ``` -JIT takes bytecodes as an input and generates [IL trees](https://github.com/eclipse/omr/blob/dd1373f8fbe46759cc02c3c6386dbee9ce30ce5e/doc/compiler/il/IntroToTrees.md). The first section is the bytecodes that are received from VM. +JIT takes bytecodes as an input and generates [IL trees](https://github.com/eclipse-omr/omr/blob/dd1373f8fbe46759cc02c3c6386dbee9ce30ce5e/doc/compiler/il/IntroToTrees.md). The first section is the bytecodes that are received from VM. - Bytecode `#1` `getfield` shows the constant pool index `38` of the field. - Bytecode `#5` `astore` stores the address to the stack slot number `6`. @@ -91,7 +91,7 @@ JIT takes bytecodes as an input and generates [IL trees](https://github.com/ecli The IL generator generated the following IL which showed up in the section `"Pre IlGenOpt Trees"`. -The IL consists of a doubly linked list of trees of nodes ([TR::Nodes](https://github.com/eclipse/omr/blob/master/compiler/il/OMRNode.hpp)). +The IL consists of a doubly linked list of trees of nodes ([TR::Nodes](https://github.com/eclipse-omr/omr/blob/master/compiler/il/OMRNode.hpp)). ``` n284n BBStart [0x7eff0a557880] bci=[-1,0,628] rc=0 vc=0 vn=- li=- udi=- nc=0 @@ -104,7 +104,7 @@ n289n BBStart (freq 0) (cold) ... ``` - - `n284n`: nodeID, or [the GlobalIndex of an TR::Node](https://github.com/eclipse/omr/blob/e4c209ac149ef8db3cc9834a962b689a2e3c0fd7/compiler/il/OMRNode.hpp#L754) + - `n284n`: nodeID, or [the GlobalIndex of an TR::Node](https://github.com/eclipse-omr/omr/blob/e4c209ac149ef8db3cc9834a962b689a2e3c0fd7/compiler/il/OMRNode.hpp#L754) that uniquely identifies a node. The node's global index can sometimes be used as an index into a bit vector or an array to get some piece of information associated with that specific node. i.e. it serves a purpose that cannot be served using just the node's address. @@ -113,8 +113,8 @@ just the node's address. - `n284n BBStart` has no children in this example. `n288n ificmpne` has two children. It compares `n286n` with `n287n`. If they are not equal, it branches to `block_2`, otherwise it will fall through to `block_33`. -- We can find the [IL opcode properties](https://github.com/eclipse/omr/blob/1d0a329e26b096dacba6f31fef33236ed419428a/compiler/il/OMROpcodes.enum#L4502-L4517) -in [OMROpcodes.enum](https://github.com/eclipse/omr/blob/1d0a329e26b096dacba6f31fef33236ed419428a/compiler/il/OMROpcodes.enum) +- We can find the [IL opcode properties](https://github.com/eclipse-omr/omr/blob/1d0a329e26b096dacba6f31fef33236ed419428a/compiler/il/OMROpcodes.enum#L4502-L4517) +in [OMROpcodes.enum](https://github.com/eclipse-omr/omr/blob/1d0a329e26b096dacba6f31fef33236ed419428a/compiler/il/OMROpcodes.enum) to figure out the number of children an IL opcode has and the types of the children. ``` @@ -325,7 +325,7 @@ this pointer is non-NULL. If this pointer is `NULL`, this method will not even h `n45n ificmpne`: Tests if `arrayLength` equals to `0`. If yes, it branches to `block_5`. If no, it falls through to the next block. -The reason that we have separate trees or treetops is because we want to order [side effects](https://github.com/eclipse/omr/blob/master/doc/compiler/il/IntroToTrees.md#side-effects) in a program. +The reason that we have separate trees or treetops is because we want to order [side effects](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/il/IntroToTrees.md#side-effects) in a program. The inexplicit order of treetop indicates the order of side effects. They happen one after another. Side effects mean that the result of an operation will have an effect even after the trees are executed. Throwing an @@ -338,7 +338,7 @@ Only one side effect exits in each treetop. We do not want one tree to have a `N ## 3. Optimization: globalValuePropagation -[Global Value Propagation](https://github.com/eclipse/omr/blob/master/doc/compiler/optimizer/ValuePropagation.md) is important because it is one place where it has the most knowledge of what the semantics +[Global Value Propagation](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/optimizer/ValuePropagation.md) is important because it is one place where it has the most knowledge of what the semantics are for different opcodes. ``` @@ -390,8 +390,8 @@ but it has a different opcode now. ``` [ 4830] O^O VALUE PROPAGATION: Constant folding lload [00007F00A30046D0] to lconst 0 ``` -[performTransformation](https://github.com/eclipse/omr/blob/6eec759cd2d446f74d2b8a7ee3348d98ce6bfa79/compiler/ras/Debug.cpp#L489) prints out the message on the above and guards whether or not the transformation performs. -`[ 4830]` indicates the number of transformations that have occurred so far. To [narrow down the transformation](https://github.com/eclipse/omr/blob/master/doc/compiler/ProblemDetermination.md#identifying-the-failing-optimization) that +[performTransformation](https://github.com/eclipse-omr/omr/blob/6eec759cd2d446f74d2b8a7ee3348d98ce6bfa79/compiler/ras/Debug.cpp#L489) prints out the message on the above and guards whether or not the transformation performs. +`[ 4830]` indicates the number of transformations that have occurred so far. To [narrow down the transformation](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/ProblemDetermination.md#identifying-the-failing-optimization) that causes a problem, we can do a binary search on these numbers by using `lastOptIndex`. If `lastOptIndex=4830`, none of the transformations after `4830` will take place. @@ -715,7 +715,7 @@ n4n BBEnd `n1104n lload` in `block_109` is replaced with `n4811n ==>lRegLoad`. `lRegLoad` is long register load. The value is now picked up from the register that is associated with `n4811n lRegLoad`. Looking at the earlier references of `n4811n` in `block_53`, `n4811n` takes the value `parm 1` and associates it with the real register `esi`. `n4811n` is also the -first child of [GlRegDeps](https://github.com/eclipse/omr/blob/6eec759cd2d446f74d2b8a7ee3348d98ce6bfa79/doc/compiler/il/GlRegDeps.md) which is the first child of `BBStart` in `block_53`. `GlRegDeps` is a request to the code +first child of [GlRegDeps](https://github.com/eclipse-omr/omr/blob/6eec759cd2d446f74d2b8a7ee3348d98ce6bfa79/doc/compiler/il/GlRegDeps.md) which is the first child of `BBStart` in `block_53`. `GlRegDeps` is a request to the code generator that the value must be in the register `esi` when coming into the `block_53`. The third child of `n642n ificmpeq` is `n4813n GlRegDeps`. When `ificmpeq` branches to `block_2`, the values that are @@ -1072,7 +1072,7 @@ checkcast exception will not be thrown. Instructions at `0x7fef12c4e570` and `0x7fef12c4e600` check if the value is `NULL`. If it is not `NULL`, it will get the class pointer and mask out the lower `8` bits and does a comparison to the class (`0x000a4100`) that is casting to. If it is equal, the checkcast succeeds. If it is not equal, it fails and throw the exception. Throwing the exception is -not handled here. We jump out of [mainline to the out-of-line](https://github.com/eclipse/omr/blob/6eec759cd2d446f74d2b8a7ee3348d98ce6bfa79/doc/compiler/il/MainlineAndOutOfLineCode.md) `Label L2066`. We do not pollute the code in the +not handled here. We jump out of [mainline to the out-of-line](https://github.com/eclipse-omr/omr/blob/6eec759cd2d446f74d2b8a7ee3348d98ce6bfa79/doc/compiler/il/MainlineAndOutOfLineCode.md) `Label L2066`. We do not pollute the code in the mainline which is executed more often. ``` diff --git a/doc/compiler/optimizer/ValuePropagation.md b/doc/compiler/optimizer/ValuePropagation.md index 00a0d6e132..6384ea6c31 100644 --- a/doc/compiler/optimizer/ValuePropagation.md +++ b/doc/compiler/optimizer/ValuePropagation.md @@ -2,7 +2,7 @@ Value propagation (VP) is one of the most powerful optimizations in the OMR compiler. It does several optimizations and analyses that one may typically find in literature, such as type propagation, constant propagation, range propagation, etc. The VP optimization combines these sorts of analyses all into one. -Every optimization in OMR can ask for certain analyses to be done ahead of time before the optimization runs. Value numbering, among other analyses, is a [prerequisite to run VP](https://github.com/eclipse/omr/blob/1d3980b61ba7ef43d0f113cf9f2ad88f79d885ab/compiler/optimizer/OMROptimizationManager.cpp#L99-L101) since the entire framework relies on having value numbers available for all nodes. +Every optimization in OMR can ask for certain analyses to be done ahead of time before the optimization runs. Value numbering, among other analyses, is a [prerequisite to run VP](https://github.com/eclipse-omr/omr/blob/1d3980b61ba7ef43d0f113cf9f2ad88f79d885ab/compiler/optimizer/OMROptimizationManager.cpp#L99-L101) since the entire framework relies on having value numbers available for all nodes. ## Value Numbering @@ -34,11 +34,11 @@ This is a very high level summary of what value numbering is. There are excellen ## Constraints and Handlers -[Value propagation constraints](https://github.com/eclipse/omr/blob/25f479d2b671c2a0a03156cc0a48024a46d2e3c2/compiler/optimizer/VPConstraint.hpp) are the fundamental classes which are flowed around by the value propagation analysis. Their purpose is the represent constraints determined by the analysis on _value numbers_. If for example we had an expression such as `x = 5` then we would create a constraint which represents the constant value of `5` and we would associate this constraint with the value numbers for the nodes representing the left hand side (`istore`) and right hand side (`iconst`) nodes. Remember that these two nodes would have the same value number because we can prove that they are equal. The VP handlers consume these relations between value numbers and constraints to optimize the program. +[Value propagation constraints](https://github.com/eclipse-omr/omr/blob/25f479d2b671c2a0a03156cc0a48024a46d2e3c2/compiler/optimizer/VPConstraint.hpp) are the fundamental classes which are flowed around by the value propagation analysis. Their purpose is the represent constraints determined by the analysis on _value numbers_. If for example we had an expression such as `x = 5` then we would create a constraint which represents the constant value of `5` and we would associate this constraint with the value numbers for the nodes representing the left hand side (`istore`) and right hand side (`iconst`) nodes. Remember that these two nodes would have the same value number because we can prove that they are equal. The VP handlers consume these relations between value numbers and constraints to optimize the program. -[Value propagation handlers](https://github.com/eclipse/omr/blob/25f479d2b671c2a0a03156cc0a48024a46d2e3c2/compiler/optimizer/VPHandlers.cpp) are functions which operate on the set of constraints associated with the node's children and produce constraints for the parent node. There are many handler functions associated with many opcodes. The [value propagation table](https://github.com/eclipse/omr/blob/ad822fbd7f17f1aa1fddafa355cb18fac4247a46/compiler/optimizer/ValuePropagationTable.hpp) describes which function to execute for each particular opcode. Some opcodes are not interesting and all they do is constrain their children, while others perform an interesting operation. +[Value propagation handlers](https://github.com/eclipse-omr/omr/blob/25f479d2b671c2a0a03156cc0a48024a46d2e3c2/compiler/optimizer/VPHandlers.cpp) are functions which operate on the set of constraints associated with the node's children and produce constraints for the parent node. There are many handler functions associated with many opcodes. The [value propagation table](https://github.com/eclipse-omr/omr/blob/ad822fbd7f17f1aa1fddafa355cb18fac4247a46/compiler/optimizer/ValuePropagationTable.hpp) describes which function to execute for each particular opcode. Some opcodes are not interesting and all they do is constrain their children, while others perform an interesting operation. -The best way to understand what a VP handler does is to look at an example. Let's consider the case for a simple integer multiplication which is handled by the [`constrainImul`](https://github.com/eclipse/omr/blob/25f479d2b671c2a0a03156cc0a48024a46d2e3c2/compiler/optimizer/VPHandlers.cpp#L5976-L6068) function. This VP handler takes the two constraints of the children of the multiplication and analyzes them. If the constraints represent constants, it multiplies the values of the children constraints and creates a new constant constraint for the parent node. If the constraints represent ranges of values the handler calculates what the maximum and minimum ranges would be of the multiplication and creates a new range constraint for the parent node. +The best way to understand what a VP handler does is to look at an example. Let's consider the case for a simple integer multiplication which is handled by the [`constrainImul`](https://github.com/eclipse-omr/omr/blob/25f479d2b671c2a0a03156cc0a48024a46d2e3c2/compiler/optimizer/VPHandlers.cpp#L5976-L6068) function. This VP handler takes the two constraints of the children of the multiplication and analyzes them. If the constraints represent constants, it multiplies the values of the children constraints and creates a new constant constraint for the parent node. If the constraints represent ranges of values the handler calculates what the maximum and minimum ranges would be of the multiplication and creates a new range constraint for the parent node. Note that if you examine how the constraints of the children are obtained, you will see that they are extracted using the node's value number. Going back to our previous example of creating a constant constraint for an `x = 5` operation it is fairly straightforward to see that for our multiplication example if one of the children happened to have the same value number as `x`, then it means we can replace the child with a constant load of `5`. It is very important to understand that the child of the multiply can be arbitrarily complicated, yet as long as it has the same value number as `x` we can reduce it to a constant. This is the essence of the value propagation optimization. @@ -64,7 +64,7 @@ A `merge` of two constraints will weaken the constraint. For example consider th ``` if (...) { - if (x != 10) + if (x != 10) return; ... } else { @@ -92,7 +92,7 @@ These constraints represent ranges of values a particular value number can take For typed languages it is often beneficial to flow type constraints. Knowing type information about a particular value number at a given point in the program can allow us to devirtualize calls or eliminate type check and exception edges. -There are three different constraint classes which flow this information in VP, they are the [fixed class](https://github.com/eclipse/omr/blob/25f479d2b671c2a0a03156cc0a48024a46d2e3c2/compiler/optimizer/VPConstraint.hpp#L655-L674) constraint, [resolved class](https://github.com/eclipse/omr/blob/25f479d2b671c2a0a03156cc0a48024a46d2e3c2/compiler/optimizer/VPConstraint.hpp#L628-L653) constraint, and [unresolved class](https://github.com/eclipse/omr/blob/25f479d2b671c2a0a03156cc0a48024a46d2e3c2/compiler/optimizer/VPConstraint.hpp#L706-L736) constraints. +There are three different constraint classes which flow this information in VP, they are the [fixed class](https://github.com/eclipse-omr/omr/blob/25f479d2b671c2a0a03156cc0a48024a46d2e3c2/compiler/optimizer/VPConstraint.hpp#L655-L674) constraint, [resolved class](https://github.com/eclipse-omr/omr/blob/25f479d2b671c2a0a03156cc0a48024a46d2e3c2/compiler/optimizer/VPConstraint.hpp#L628-L653) constraint, and [unresolved class](https://github.com/eclipse-omr/omr/blob/25f479d2b671c2a0a03156cc0a48024a46d2e3c2/compiler/optimizer/VPConstraint.hpp#L706-L736) constraints. Fixed class constraints simply express that a value number has a specific, fixed, type `T`. We can know this information perhaps because we have seen the allocation of the value number expression or perhaps we have seen an explicit cast into type `T` where `T` is a `final` type (meaning it cannot be subtyped). Knowing the exact type of a value number expression is the most useful. @@ -102,7 +102,7 @@ Unresolved class constraints are least interesting and express that the class ty ### Null and NonNull Constraints -There are two notions flowed through VP for reference types in regards to nullness. The [null](https://github.com/eclipse/omr/blob/25f479d2b671c2a0a03156cc0a48024a46d2e3c2/compiler/optimizer/VPConstraint.hpp#L746-L760) constraint, and the [non-null](https://github.com/eclipse/omr/blob/25f479d2b671c2a0a03156cc0a48024a46d2e3c2/compiler/optimizer/VPConstraint.hpp#L762-L775) constraint. These constraints are useful for tracking value numbers which are certainly known to be either `null` or certainly not `null`. Knowing such information can eliminate implicit and explicit null checks or open doors for further simplifications, such as folding away of comparisons (`ifacmpeq/ne`) that test against `null`. +There are two notions flowed through VP for reference types in regards to nullness. The [null](https://github.com/eclipse-omr/omr/blob/25f479d2b671c2a0a03156cc0a48024a46d2e3c2/compiler/optimizer/VPConstraint.hpp#L746-L760) constraint, and the [non-null](https://github.com/eclipse-omr/omr/blob/25f479d2b671c2a0a03156cc0a48024a46d2e3c2/compiler/optimizer/VPConstraint.hpp#L762-L775) constraint. These constraints are useful for tracking value numbers which are certainly known to be either `null` or certainly not `null`. Knowing such information can eliminate implicit and explicit null checks or open doors for further simplifications, such as folding away of comparisons (`ifacmpeq/ne`) that test against `null`. Note that although these constraint classes exist, we typically query them through the `VPClass` base class constraint. It is usually more convenient and efficient to store all the various information about a reference type in this base class, rather than storing multiple individual constraints for type, nullness, etc. @@ -180,7 +180,7 @@ For some optimizations, the context information available during value propagati Because value propagation relies on all nodes having valid value numbers it is impossible for us to perform a transformation which creates a new node out of thin air during the analysis. This is because for loop back edges for example we may visit the same node twice, and we could potentially encounter a node without a value number. We could of course create a unique value number for this new node at the point of creation, but for one reason or another we chose to handle such operations by employing the notion of _delayed transformations_. -During value propagation if we encounter a situation where we would like to create a brand new node, what we do is we record this node into a list for later processing. Once the the value propagation analysis is done we no longer have a need for the value numbers, and we can safely process all the recorded nodes. This operation is done by the [doDelayedTransformations](https://github.com/eclipse/omr/blob/25f479d2b671c2a0a03156cc0a48024a46d2e3c2/compiler/optimizer/OMRValuePropagation.hpp#L467) API. +During value propagation if we encounter a situation where we would like to create a brand new node, what we do is we record this node into a list for later processing. Once the the value propagation analysis is done we no longer have a need for the value numbers, and we can safely process all the recorded nodes. This operation is done by the [doDelayedTransformations](https://github.com/eclipse-omr/omr/blob/25f479d2b671c2a0a03156cc0a48024a46d2e3c2/compiler/optimizer/OMRValuePropagation.hpp#L467) API. Note that if we want to transmute node `A` into node `B` we can still do so during the analysis phase as long as both node `A` and node `B` have valid value numbers. Similarly we can eliminate nodes from the program by simply removing them (for example eliminating `null` checks). diff --git a/doc/compiler/osr/OSR.md b/doc/compiler/osr/OSR.md index eae875c10e..24ae5497f3 100644 --- a/doc/compiler/osr/OSR.md +++ b/doc/compiler/osr/OSR.md @@ -39,7 +39,7 @@ In addition, if assumptions that the compiler made while compiling a method are A VM event can be detected at certain points during execution of compiled code. These points are called **OSR yield points**. The JIT and the VM agree on the set of OSR yield points. -Usually, we would like the VM event to be discovered relatively soon after it took place. [Garbage Collection (GC) points](https://github.com/eclipse/omr/blob/81b79405da6c7c960e611a8b2b12fd5861543330/compiler/il/OMRNode.cpp#L2298) meet such criteria. +Usually, we would like the VM event to be discovered relatively soon after it took place. [Garbage Collection (GC) points](https://github.com/eclipse-omr/omr/blob/81b79405da6c7c960e611a8b2b12fd5861543330/compiler/il/OMRNode.cpp#L2298) meet such criteria. Therefore, depending on the event, OSR yield points usually include all or a subset of GC points. The reason why we would like to limit the set of OSR yield points, if possible, is the cost of the bookkeeping associated with each such point as well as the restrictions that they impose on the optimizer. @@ -248,4 +248,4 @@ and then continues execution without any other debugging actions. ```osrLiveRangeAnalysis```: calculates autos and pending push temporaries liveness info at the OSR points. If pending push temporaries liveness was calculated during ILGen it is reused by this analysis. -```OSRDefAnalysis```: Used by ```osrLiveRangeAnalysis```. \ No newline at end of file +```OSRDefAnalysis```: Used by ```osrLiveRangeAnalysis```. diff --git a/doc/compiler/riscv/Building.md b/doc/compiler/riscv/Building.md index 5d6a5698ab..f407e2ff92 100644 --- a/doc/compiler/riscv/Building.md +++ b/doc/compiler/riscv/Building.md @@ -16,7 +16,7 @@ can get them using (the image created using [debian-riscv][1] contains them): ### Building ``` -git clone https://github.com/eclipse/omr +git clone https://github.com/eclipse-omr/omr cd omr mkdir build cd build @@ -163,4 +163,4 @@ To run selected TRIL tests: ~/qemu/riscv64-linux-user/qemu-riscv64 -L ~/riscv-debian/rootfs ./comptest --gtest_filter=*Arithmetic*/Int32*:LogicalTest/Int32*Unary* [1]: https://github.com/janvrany/riscv-debian -[2]: https://www.debian.org/News/2019/20190706 \ No newline at end of file +[2]: https://www.debian.org/News/2019/20190706 diff --git a/doc/compiler/x/OpCodeEncoding.md b/doc/compiler/x/OpCodeEncoding.md index 44dd0edca2..9b024a9718 100644 --- a/doc/compiler/x/OpCodeEncoding.md +++ b/doc/compiler/x/OpCodeEncoding.md @@ -10,7 +10,7 @@ is available at https://www.apache.org/licenses/LICENSE-2.0. This Source Code may also be made available under the following Secondary Licenses when the conditions for such availability set forth in the Eclipse Public License, v. 2.0 are satisfied: GNU -General Public License, version 2 with the GNU Classpath +General Public License, version 2 with the GNU Classpath Exception [1] and GNU General Public License, version 2 with the OpenJDK Assembly Exception [2]. @@ -20,7 +20,7 @@ OpenJDK Assembly Exception [2]. SPDX-License-Identifier: EPL-2.0 OR Apache-2.0 OR GPL-2.0-only WITH Classpath-exception-2.0 OR GPL-2.0-only WITH OpenJDK-assembly-exception-1.0 --> -# X86 Binary Encoding Scheme - Issue [#425](https://github.com/eclipse/omr/issues/425) +# X86 Binary Encoding Scheme - Issue [#425](https://github.com/eclipse-omr/omr/issues/425) OMR's X86 Binary Encoding Scheme is inspired by Intel's VEX and EVEX prefixes, which compact mandatory prefixes and multi-byte opcode escape codes into 2 bits each. @@ -170,7 +170,7 @@ generateRegRegInstruction(TR::InstOpCode::MOVDQURegReg, node, resultReg, valueRe #### Dynamically determining the best encoding method -To dynamically find the best encoding method you may [call](https://github.com/eclipse/omr/blob/e0dde228728f4dd7cf48e407971e01b0fcc130fe/compiler/x/codegen/OMRInstOpCode.hpp#L504) +To dynamically find the best encoding method you may [call](https://github.com/eclipse-omr/omr/blob/e0dde228728f4dd7cf48e407971e01b0fcc130fe/compiler/x/codegen/OMRInstOpCode.hpp#L504) ```OMR::InstOpCode::getSIMDEncoding(&cpu, vl)```. This query uses flags stored on the instruction to determine the best encoding method for the given instruction, CPU, and vector length. diff --git a/doc/diagnostics/CallingConventions.md b/doc/diagnostics/CallingConventions.md index bc8f84ce70..a1895b2acf 100644 --- a/doc/diagnostics/CallingConventions.md +++ b/doc/diagnostics/CallingConventions.md @@ -317,4 +317,4 @@ Scratch registers are not preserved across calls, while non-volatile registers a Useful links: * [RISC-V ELF psABI specification](https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md#register-convention) - * [RVSystemLinkage.cpp](https://github.com/eclipse/omr/blob/master/compiler/riscv/codegen/RVSystemLinkage.cpp) + * [RVSystemLinkage.cpp](https://github.com/eclipse-omr/omr/blob/master/compiler/riscv/codegen/RVSystemLinkage.cpp) diff --git a/doc/images/addition-of-a-fork.svg b/doc/images/addition-of-a-fork.svg index a66c881dd7..e4cb7ff384 100644 --- a/doc/images/addition-of-a-fork.svg +++ b/doc/images/addition-of-a-fork.svg @@ -1,2 +1,2 @@ -
github.com/eclipse/omr
github.com/eclipse/omr<br>
github.com/leonardo/omr
github.com/leonardo/omr<br>
github.com/xiaoli/omr
github.com/xiaoli/omr<br>
github.com/dhruv/omr
github.com/dhruv/omr<br>
github.com/yourgithub/omr
github.com/yourgithub/omr<br> \ No newline at end of file +
github.com/eclipse-omr/omr
github.com/eclipse-omr/omr<br>
github.com/leonardo/omr
github.com/leonardo/omr<br>
github.com/xiaoli/omr
github.com/xiaoli/omr<br>
github.com/dhruv/omr
github.com/dhruv/omr<br>
github.com/yourgithub/omr
github.com/yourgithub/omr<br> diff --git a/doc/images/distributed-vcs-model.svg b/doc/images/distributed-vcs-model.svg index d409fd8ad3..a74633f0c6 100644 --- a/doc/images/distributed-vcs-model.svg +++ b/doc/images/distributed-vcs-model.svg @@ -1,2 +1,2 @@ -
github.com/eclipse/omr
github.com/eclipse/omr<br>
github.com/leonardo/omr
github.com/leonardo/omr<br>
github.com/xiaoli/omr
github.com/xiaoli/omr<br>
github.com/dhruv/omr
github.com/dhruv/omr<br> \ No newline at end of file +
github.com/eclipse-omr/omr
github.com/eclipse-omr/omr<br>
github.com/leonardo/omr
github.com/leonardo/omr<br>
github.com/xiaoli/omr
github.com/xiaoli/omr<br>
github.com/dhruv/omr
github.com/dhruv/omr<br> diff --git a/doc/images/omr-dev-workflow.svg b/doc/images/omr-dev-workflow.svg index ea94085eb6..08c0212041 100644 --- a/doc/images/omr-dev-workflow.svg +++ b/doc/images/omr-dev-workflow.svg @@ -1,2 +1,2 @@ -
github.com/eclipse/omr
github.com/eclipse/omr<br>
github.com/yourgithub/omr
github.com/yourgithub/omr<br>
~/omr
~/omr
fork
fork<br>
clone
clone<br>
push
push<br>
fetch
fetch<br>
origin
origin<br>
upstream
upstream<br>
pull request
pull request<br>
fetch
fetch<br>
local
local<br> \ No newline at end of file +
github.com/eclipse-omr/omr
github.com/eclipse-omr/omr<br>
github.com/yourgithub/omr
github.com/yourgithub/omr<br>
~/omr
~/omr
fork
fork<br>
clone
clone<br>
push
push<br>
fetch
fetch<br>
origin
origin<br>
upstream
upstream<br>
pull request
pull request<br>
fetch
fetch<br>
local
local<br> diff --git a/fvtest/tril/README.md b/fvtest/tril/README.md index 7babaa62d8..5b93b05e76 100644 --- a/fvtest/tril/README.md +++ b/fvtest/tril/README.md @@ -10,7 +10,7 @@ is available at https://www.apache.org/licenses/LICENSE-2.0. This Source Code may also be made available under the following Secondary Licenses when the conditions for such availability set forth in the Eclipse Public License, v. 2.0 are satisfied: GNU -General Public License, version 2 with the GNU Classpath +General Public License, version 2 with the GNU Classpath Exception [1] and GNU General Public License, version 2 with the OpenJDK Assembly Exception [2]. @@ -45,7 +45,7 @@ The `test/` directory contains some GTest-based test cases for Tril. 2. Clone the Eclipse OMR repo: ```sh - git clone https://github.com/eclipse/omr.git + git clone https://github.com/eclipse-omr/omr.git ``` 3. Build tril using `cmake`. To ensure OMR gets built in a compatible @@ -59,7 +59,7 @@ The `test/` directory contains some GTest-based test cases for Tril. ``` At this point you can use whatever generated build system to build - tril: + tril: ``` make tril @@ -68,7 +68,7 @@ The `test/` directory contains some GTest-based test cases for Tril. 5. You should now have a static archive called `libtril.a` 6. You can build the tests by building `triltest`, or the compiler tests built - using tril by by building `comptest`. There's also the `mandelbrot` and `incordec` + using tril by by building `comptest`. There's also the `mandelbrot` and `incordec` examples. 4. Enjoy the view! diff --git a/jitbuilder/apigen/schema/api-class.schema.json b/jitbuilder/apigen/schema/api-class.schema.json index 554b5d6da8..7cc6ed5743 100644 --- a/jitbuilder/apigen/schema/api-class.schema.json +++ b/jitbuilder/apigen/schema/api-class.schema.json @@ -1,6 +1,6 @@ { "$schema": "http://json-schema.org/draft-07/schema#", - "$id": "https://raw.githubusercontent.com/eclipse/omr/master/jitbuilder/apigen/schema/api-class.schema.json", + "$id": "https://raw.githubusercontent.com/eclipse-omr/omr/master/jitbuilder/apigen/schema/api-class.schema.json", "title": "API Class Description Format", "description": "Format for specifying API classes", "$comment": "Copyright IBM Corp. and others 2018 (see LICENSE.md)", diff --git a/jitbuilder/apigen/schema/api-field.schema.json b/jitbuilder/apigen/schema/api-field.schema.json index 94b72c5b7e..cd49ee2372 100644 --- a/jitbuilder/apigen/schema/api-field.schema.json +++ b/jitbuilder/apigen/schema/api-field.schema.json @@ -1,6 +1,6 @@ { "$schema": "http://json-schema.org/draft-07/schema#", - "$id": "https://raw.githubusercontent.com/eclipse/omr/master/jitbuilder/apigen/schema/api-field.schema.json", + "$id": "https://raw.githubusercontent.com/eclipse-omr/omr/master/jitbuilder/apigen/schema/api-field.schema.json", "title": "API Field Description Format", "description": "Format for specifying API fields", "$comment": "Copyright IBM Corp. and others 2018 (see LICENSE.md)", diff --git a/jitbuilder/apigen/schema/api-service.schema.json b/jitbuilder/apigen/schema/api-service.schema.json index 96c28669b0..7d7aaedfec 100644 --- a/jitbuilder/apigen/schema/api-service.schema.json +++ b/jitbuilder/apigen/schema/api-service.schema.json @@ -1,6 +1,6 @@ { "$schema": "http://json-schema.org/draft-07/schema#", - "$id": "https://raw.githubusercontent.com/eclipse/omr/master/jitbuilder/apigen/schema/api-service.schema.json", + "$id": "https://raw.githubusercontent.com/eclipse-omr/omr/master/jitbuilder/apigen/schema/api-service.schema.json", "title": "API Service Description Format", "description": "Format for specifying API services", "$comment": "Copyright IBM Corp. and others 2018 (see LICENSE.md)", diff --git a/jitbuilder/apigen/schema/api-type.schema.json b/jitbuilder/apigen/schema/api-type.schema.json index c71a27e107..1136e11ad4 100644 --- a/jitbuilder/apigen/schema/api-type.schema.json +++ b/jitbuilder/apigen/schema/api-type.schema.json @@ -1,6 +1,6 @@ { "$schema": "http://json-schema.org/draft-07/schema#", - "$id": "https://raw.githubusercontent.com/eclipse/omr/master/jitbuilder/apigen/schema/api-type.schema.json", + "$id": "https://raw.githubusercontent.com/eclipse-omr/omr/master/jitbuilder/apigen/schema/api-type.schema.json", "title": "API Datatype Description Format", "description": "Format for specifying API datatypes", "$comment": "Copyright IBM Corp. and others 2018 (see LICENSE.md)", diff --git a/jitbuilder/apigen/schema/api.schema.json b/jitbuilder/apigen/schema/api.schema.json index b7e80ed52e..7369bdeb7a 100644 --- a/jitbuilder/apigen/schema/api.schema.json +++ b/jitbuilder/apigen/schema/api.schema.json @@ -1,6 +1,6 @@ { "$schema": "http://json-schema.org/draft-07/schema#", - "$id": "https://raw.githubusercontent.com/eclipse/omr/master/jitbuilder/apigen/schema/api.schema.json", + "$id": "https://raw.githubusercontent.com/eclipse-omr/omr/master/jitbuilder/apigen/schema/api.schema.json", "title": "API Description Format", "description": "Format for describing framework and library APIs in a way that allows simple generation of language bindings", "$comment": "Copyright IBM Corp. and others 2018 (see LICENSE.md)", diff --git a/jitbuilder/release/README.md b/jitbuilder/release/README.md index 19e9c60480..6242e87493 100644 --- a/jitbuilder/release/README.md +++ b/jitbuilder/release/README.md @@ -10,7 +10,7 @@ is available at https://www.apache.org/licenses/LICENSE-2.0. This Source Code may also be made available under the following Secondary Licenses when the conditions for such availability set forth in the Eclipse Public License, v. 2.0 are satisfied: GNU -General Public License, version 2 with the GNU Classpath +General Public License, version 2 with the GNU Classpath Exception [1] and GNU General Public License, version 2 with the OpenJDK Assembly Exception [2]. @@ -25,7 +25,7 @@ SPDX-License-Identifier: EPL-2.0 OR Apache-2.0 OR GPL-2.0-only WITH Classpath-ex A library for dynamically generating efficient native code and, in particular, for building JIT compilers using the Eclipse OMR JIT compiler component -(see [Eclipse OMR Project](https://github.com/eclipse/omr)). +(see [Eclipse OMR Project](https://github.com/eclipse-omr/omr)). To use JitBuilder, you create `IlBuilder` objects to represent the various control flow paths in a function you're trying to create @@ -66,7 +66,7 @@ run the many available code samples from the C++ language. First, clone the Eclipse OMR repository: ``` -$ git clone https://github.com/eclipse/omr +$ git clone https://github.com/eclipse-omr/omr ``` Change directory into the OMR project, create a `build` directory, and diff --git a/scripts/commit-msg b/scripts/commit-msg index 04ec34a01f..e01c645103 100644 --- a/scripts/commit-msg +++ b/scripts/commit-msg @@ -25,7 +25,7 @@ # each git commit message against OMR contributing guidelines. The script # needs to be executable and it will be invoked when a 'git commit' command # is issued. OMR contributing guidelines can be found at: -# https://github.com/eclipse/omr/blob/master/CONTRIBUTING.md#commit-guidelines +# https://github.com/eclipse-omr/omr/blob/master/CONTRIBUTING.md#commit-guidelines message_file = ARGV[0] message = File.read(message_file) @@ -103,7 +103,7 @@ end # display results if (state == "failure") puts "FAILED: #{description}" - puts "Please see guidelines: https://github.com/eclipse/omr/blob/master/CONTRIBUTING.md#commit-guidelines\n" + puts "Please see guidelines: https://github.com/eclipse-omr/omr/blob/master/CONTRIBUTING.md#commit-guidelines\n" exit 1 end