Make target environment local to the compiler

[dsouzai]

The compiler uses the TR::Compiler singleton to query against the TR::Environment target which is used to determine the environment the native generated code is targeting. This approach works fine for when the compiler is always going to generate code for a particular target. However, in dynamic runtimes that want to provide the ability to have optional dynamic relocatable compilations¹, the compiler needs to have the ability to switch between at least two different target environments: 1. where the target environment matches the host environment, and 2. where the target environment does not.

One way of going forward would be:

1. Add another TR::Environment member to OMR::CompilerEnv, say (for lack of a better name) relocatableTarget.
2. Initialize the two targets (once) accordingly
3. Add a TR::Environment member to OMR::Compilation
4. Depending on the type of compilation (relocatable, or otherwise), copy construct the appropriate target into the compilation-local environment
5. Update all uses of TR::Compiler->target to comp()->target()

Further considerations

I believe it would be beneficial to have the ability to accept options to control the target processor as well as processor features. Currently in the compiler, for P and Z, the CPU features are coupled with the processor so knowing the processor level generally indicates what features are available for use. However, this may not continue to be the trend, and is already not the case with x86 and AArch64. Therefore, supporting an option to target a processor would be convenient to address the current coupling in P and Z, but we also accept target processor features as options for other architectures. In the case of relocatable compilations, the default behaviour could just be to target only the core features of the ISA.

---

1 - By "optional dynamic relocatable compilation", I mean the decision to compile some entity is made at runtime (dynamic) and the decision to generate position independent code for a particular compilation (relocatable compilation) is also made at runtime (optional).

[janvrany]

However, this may not continue to be the trend, and is already not the case with x86 and AArch64.

It not the case of RISC-V, either.

[DanHeidinga]

In the case of relocatable compilations, the default behaviour could just be to target only the core features of the ISA.

Does it make sense to support the equivalent of gcc's -mtune & -march flags for relocatable compilations? Then the language environments can tune for particular feature sets with the default being the current ISA.

[dsouzai]

Yeah the discussion more or less went along the lines of eventually having the ability to specify particular feature sets, as I described the motivation on the OpenJ9 side. As a first step, the consensus was to go ahead with first refactoring the code to make the target a compilation local entity to facilitate the ability to specify feature sets.

[dsouzai]

I still have to test out my changes on multiple platforms, but I managed to replace most uses of TR::Compiler->target with something along the lines of COMP_QUERY->target() where COMP_QUERY varies (eg comp(), cg->comp(), cg()->comp(), etc).

Now what remains is somewhat non-trivial:

1. Uses in compiler/codegen/ELFGenerator.cpp
2. https://github.com/eclipse/omr/blob/e74d024550f3ae4472f23a984faa5c76c7e109b9/compiler/control/CompileMethod.cpp#L146
3. Uses in compiler/control/OMROptions.cpp
4. https://github.com/eclipse/omr/blob/e74d024550f3ae4472f23a984faa5c76c7e109b9/compiler/env/OMRObjectModel.cpp#L47-L50
5. https://github.com/eclipse/omr/blob/e74d024550f3ae4472f23a984faa5c76c7e109b9/compiler/il/OMRILOps.cpp#L65-L68
6. Uses in compiler/ilgen/OMRILBuilder.cpp
7. https://github.com/eclipse/omr/blob/e74d024550f3ae4472f23a984faa5c76c7e109b9/compiler/ilgen/OMRTypeDictionary.cpp#L487
8. https://github.com/eclipse/omr/blob/e74d024550f3ae4472f23a984faa5c76c7e109b9/compiler/ras/DebugCounter.hpp#L182
9. https://github.com/eclipse/omr/blob/e74d024550f3ae4472f23a984faa5c76c7e109b9/compiler/x/codegen/OMRSnippet.hpp#L96-L102
10. https://github.com/eclipse/omr/blob/e74d024550f3ae4472f23a984faa5c76c7e109b9/compiler/ilgen/IlInjector.cpp#L96-L99

@Leonardo2718 @andrewcraik @0xdaryl could you please provide guidance?

[0xdaryl]

Proper cross compilation support has not been architected into OMR or downstream projects yet (see #1674 for a starting point). There are currently baked-in assumptions about the homogeneity of the target by each compilation thread and by compiler initialization and runtime code. Your PR relaxes those somewhat for the CPU capability questions on the target for individual compilation threads, but there are still places in the code outside of a compilation context (e.g., compiler initialization or compilation runtime) that assume a level of consistency in the environment. For just one example, only one code cache is allocated and managed and its configuration is based on an assumption of the target environment (e.g., that all the code will be for a particular processor architecture and will be of the same bitness).

Until broader cross compilation support is in place, I believe the assumption needs to be that for a given build of the compiler that the environment (the target OS, target bitness, number of processors) needs to be consistent across all compilation threads and for the runtime parts outside of compilation threads. The target CPU architecture (and endianness) should be fixed, but the exact family of processor and the capabilities available on those processors can vary between compilation threads.

Hence, as long as the target CPU question isn't about whether a particular processor feature is available I think it is safe to ask the global environment for the answer (e.g., number of processors, target architecture, etc.).

[dsouzai]

Assuming my changes go in, how would we enforce that new code does not use TR::Compiler->target unless outside of a compilation? Adding TR_ASSERT_FATAL(TR::comp() == NULL) perhaps? It would need to wait until these changes were propagated to all extending projects.

EDIT: Actually the assert wouldn't even work, the target isn't accessed via a query. I guess we could change it so that it was accessed via a query.