Get information outside the dialect

traditionally speaking, hardware specific dialect is behind
but how can front dialect get information from other dialects?

for example, there is A dialect and B dialect, the lower sequence will be :
A dialect → B dialect
A dialect needs information from B dialect.

more specific example, partial ops in A dialect will be lowered to B dialect
it depends on what operators are supported in B…

there is attribute for dialect, but it is constant information
is there other approach ?
many thanks

One way for create a communication channel between dialects is to use operation interfaces. The “A” dialect can provide separate set of interfaces, while the “B” dialect can implement them as external models and attach to “A” dialect’s operations. The interfaces can be put to separate library to avoid hard fdependency between dialects.

It’s unclear what do you mean by “supported in B”. The lowering pass will depend on both A and B anyway, so it can use any knowledge of B it wants. If it needs some queries, it can obtain a BDialect from the context and the BDialect class can provide methods perform the queries.

Let’s say A (Memory dialect) can be lowered to B(GPU dialect) and C(CPU dialect)
A (Memory dialect) has optimization passes which needs hardware specific information from B or C dialect

is there dedicate example in existing MLIR code or project based on MLIR ?

What prevents you from having a pass that depends on A,B and C or a pair of passes with A,B and A,C as dependencies, respectively? This pass can, and likely should, live in a library separate from the individual dialects.

I think the question gets more into something like LLVM TTI (Target Transform Info): how do you structure the concept of a “target” and build an optimization pipeline that adapts to a particular target.
Basically the multi-level approach of MLIR works great, but we need cross-level information when we build an end-to-end pipeline, where the higher level “knows” aspects of the lower levels. I don’t think op interfaces are providing an answer there, and I’m not aware of some project which built a good infra to support this. Right now I suspect most would build this in ad-hoc fashion instead.

I think @ThomasRaoux is working on something similar for IREE early in the new year. From what I’ve seen, the MLIR projects are early in their evolution and are either not adapting to targets or are using something blunt like a target triple. It’d be better to decompose a structure of attributes from something like a triple, imo.

I’m not sure how much of this even makes sense in MLIR proper as it is more of a convention for constructing specific compilers.

is this a solution ?

No it is totally unrelated.