Make Tril and Tril's tests 'backend' agnostic

[mgaudet]

The OMR compiler technology by itself is not a complete artifact. As a result of this, a testing framework like Tril needs to be able to hook itself into a completed artifact. In a very real sense, this is is Tril acting as a compiler front-end, plugging into one a completed artifact as a backend.

Currently, the backend is JitBuilder. However, Tril was designed to support multiple backends (and conceptually, could host them simultaneously, though building would be a challenge). Unfortunately, because that support was more theoretical than practical, what has happened is that the concrete backend selection has leaked, and so you'll find tests riddled with references to the Tril::JitBuilderCompiler.

The question is ultimately how to pursue this goal:

• Should the selection of backend be compile time only?
• Should we support multiple backends in one build (and would that work with the compiler technology, or would colliding symbols cause ruin).

My initial thoughts are that we need to replace #include "jitbuilder_compiler.hpp" with #include "default_compiler.hpp", and Tril::DefaultCompiler, then setup DefaultCompiler to alias with Tril::JitBuilderCompiler

[Leonardo2718]

Being able to support different compiler backends is indeed an important requirement for Tril.

For simplicity, I would start by only supporting using a single backend at a time and selecting it at compile time.

As a first step to support running Tril-based tests using different backends, we can add a virtual Tril::MethodCompiler& GetTrilCompiler() method (maybe * instead of &) to TRTest::JitTest; the base test fixture for all Tril-based compiler tests. This method can return a concrete instance of the Tril::MethodCompiler interface (e.g. Tril::JitBuilderCompiler). Then, instead of explicitly creating an instance of Tril::JitBuilderCompiler, tests can simply call TRTest::JitTest::getTrilCompiler() and use whatever instance is returned. Different implementations of the method can be guarded with #if defined() or #elif defined(). Command line arguments to the compiler can then be adjusted to select different backends.

A more sophisticated approach could use the extensible class mechanism used by the compiler technology (or something similar).

Actually doing this work will likely require some redesign however. So, as part of this issue, I think it is important to consider what the expectations of the Tril::MethodCompiler interface are. These need to be the common properties of all backends that Tril will support. A non-exhaustive list:

• What is a backend required to do when Tril::MethodCompiler::compile() is called?
• Should there be a Tril::MethodCompiler::compileWithVerifier()?
• If yes, what should the behaviour be if it is called on a backend that does not support running the IlVerifier? Or, should all backends support running with a verifier?

[mgaudet]

I have a PR to open shortly that works for this, but will be WIP.