Framework for handling combined lowering of ops/overriding default conversion functions

[jsjodin]

This draft PR does three things.

1. It implements one way of handling lowering of operations inside vs outside a target region, by selecting a different dispatch function if the op has a omp.target parent. See convertTargetDeviceTopLevelOp and the other convert functions.
2. It adds a way to match multiple nested operations via a template function, so that the parameters get bound to the matching ops. The top level function for this is matchOpNest(Operation *op, OpTypes... matchOp)
3. It implements a way to override the default dispatching of operations by having a list of conversion functions which do the conversion instead of the standard lowering op if a function exists that matches the operation being lowered. This is done using the ConversionDispatchList class.

I think the overriding and matching functionality will be pretty flexible to use since the lowering can be done directly, or if needed the dispatch override can be used in case generic lowering needs to happen as well in some of the inner regions of the operations.

[bhandarkar-pranav]

Thanks @jsjodin - I am very new to this codebase, yet I am diving into this review as if I have been working on this for months. So, please take my comments with a large grain of salt.

I get the idea of what you are trying to achieve by way of this draft PR, but had some comments and questions which I have left as inline comments.

nit
A minor nit (unrelated to this PR entirely) I have about this component in general is that I wish the entry point had been called translateOperation because that would have been consistent with MLIR's own published glossary that defines conversion as converting from one dialect to another but staying in the MLIR world, while translation is moving in or out of MLIR.
/nit

[bhandarkar-pranav]

Where is dispatchList populated?

[jsjodin]

It is populated in the the composite lowering function so that the function defined specifically for that composite construct will be called instead of the default conversion function.

[bhandarkar-pranav]

This returns at the first instance of success. Shouldn't we go through the entire dispatch list to convert every constituent construct of the composite construct?

[jsjodin]

That happens recursively in the conversions functions, only one lowering function is called per op.

[bhandarkar-pranav]

These functions are called when convertOperation is called on dispatchList, but that seems to be happening before we get into convertOmpDistributeParallelWsLoop. Am I missing something?

[jsjodin]

Initially this list is empty and only is populateed if there are enclosing op that causes inner ops to be lowered differently and need modified conversion functions.

[jsjodin]

This was already merged into ATD in the merge from main that Sergio worked on.