Dialect Extensions

[NeuralCoder3]

Often, one wants to keep a dialect extensible such that other dialects can attach at a well-defined interface.
An example would be a backend dialect that allows for dialects to handle code emission of new axioms.

This would also augment the rule construct on the cpp site for extensions that go beyond rewrites.

In general, such extension points could take the form of a map/list of functions that the dialect invokes.
The main difficulty in this approach is that the map with its type signature as well as interfacing declarations
have to be visible from other dialects.

A first step towards inter-dialect extensions, visibility, and backend extensions is in
https://github.com/NeuralCoder3/thorin2/tree/dialect_backends

[leissa]

I'd prefer a design where we put as much stuff as possible within Thorin itself. For example, we should simply expose all different passes/phases as Thorin meta programs. This way the user can simply define their own compilation pipeline or maybe invoke very specific transformations at specific parts in the program. This fixes the pragma problem approaches like OpenMP have and extends the vectorize/parallel etc idiom that we did on master.
Check out this inspiring paper @michel-steuwer pointed me at:
https://homepages.inf.ed.ac.uk/gdp/publications/compiler-forest.pdf

E.g. we could so sth like this and let the user explicitly decide where to fire the expensive exponential optimizer:

for i in expensive_optimizations(loop) {
    // ...
}

Another useful thing is "failing is an option". With Thorin we have a super powerful language. But realistically we won't be able to compile each and every edge case that you can build with such language. Now, if you expose the compilation itself as a function the programmer has to invoke, the function may return Failure with an error message. E.g., if you want to vectorize code that contains higher-order functions, exceptions and what not, it is probably best for everyone involved, to simply report to the user back

sorry, I cannot vectorize this functions because you are using exceptions.

Another example would be the LLVM backend failing (see #108 and #9) with sth like

cannot compile this functions as it makes use of other nested functions; consider running clos_conv first

But I think we should take this discussion to a virtual meeting before we rush anything here.

[leissa]

Just tagging @michel-steuwer

[leissa]

I think we can close this due to the %compile and %opt plugins.