Standardize evaluator names across backends

[fjeremic]

Standardize evaluator names across all backends to be of the form:

<ilName>Evaluator

The tree evaluator table is now generated using Opcodes.enum IL macro definitions and has been commoned up in the common code generator. Backends must implement all of the evaluator functions to be able to compile. As we continue our unification journey we can start to pull up common definitions into the common codegen. For example we can reach a state where all the evaluators are implemented in the common codegen to delegate to unImpOpEvaluator as an example.

Further, backends and downstream projects are now able to override evaluator implementations by using the extensible class mechanism and simply defining a function in the TreeEvaluator class. For example in a hypothetical downstream project, one can do:

DownstreamProject::X86::TreeEvaluator::iaddEvaluator(TR::Node *node, TR::CodeGenerator *cg)
{
    // My custom iadd evaluator
}

Closes: #5703

[fjeremic]

Jenkins build all

[fjeremic]

@dsouzai / @0xdaryl this will require a coordinated merge from one of you.

[dsouzai]

I'm not sure I understand the two Override isILOpCodeSupported commits. Because of

bool OMR::CodeGenerator::isILOpCodeSupported(TR::ILOpCodes o)
   {
	return (_nodeToInstrEvaluators[o] != TR::TreeEvaluator::unImpOpEvaluator) &&
	      (_nodeToInstrEvaluators[o] != TR::TreeEvaluator::badILOpEvaluator);
   }

given that all opcodes have their own evaluator now, OMR::CodeGenerator::isILOpCodeSupported is never going to return true. So why even bother having a case for TR::a2i? Why not just implement the evaluator for it and have it call TR::TreeEvaluator::unImpOpEvaluator?

But if the old behaviour is desired, then shouldn't there be way more cases for all of the different evaluators that are basically a wrapper around TR::TreeEvaluator::unImpOpEvaluator/TR::TreeEvaluator::badILOpEvaluator and shouldn't these be overriden in all platforms?

[fjeremic]

But if the old behaviour is desired, then shouldn't there be way more cases for all of the different evaluators that are basically a wrapper around TR::TreeEvaluator::unImpOpEvaluator/TR::TreeEvaluator::badILOpEvaluator and shouldn't these be overriden in all platforms?

There should be, but there appears to be currently no tests for such IL. The only such case I encountered was for a2i which has tests in the compilertest directory (non-Tril unit tests). The current solution is not great because isILOpCodeSupported is incomplete. However rather than going through each codegen and figuring out the set of IL that it doesn't support and adding it to the various lists there, we instead did the bare minimum to get all the tests to pass.

If someone introduces additional tests for IL that is not supported on some platforms, the tests will fail and we'll need to update isILOpCodeSupported at that time. Honestly though, I think this API should not exist at all. Our IL claims to be platform agnostic, and it should be implemented as such.

[dsouzai]

Alright, I can accept that as a current limitation. Probably worth opening an issue we can link to the housekeeping efforts (unless it's already being addressed by you in a future PR).

[knn-k]

I opened #6040 to remove duplicated definitions of some evaluators for AArch64.