[Mlir-commits] [mlir] [mlir][mpi] Lowering Mpi To LLVM (PR #127053)

[Tobias Grosser]

tobiasgrosser wrote:

> > Why would configuration parameters change anything about the issue you are mentioning? Whatever was configured can or cannot conflict later, no matter what. Notice that later is not when the compiler is built, but when the compiler is executed. If you are concerned about other passes/dialects using a different MPI in the same build, we could move finding the header-file to an upper level cmake file. Frankly, I don't see this as a problem.
> 
> I was referring to lowering pass options that can be passed into the compiler, i.e., compiling to a specific MPI implementation/draft instead of tying the supported MPI implementation to the configuration time of MLIR itself.
> 
> In any case, I don't feel confident to judge if this is an acceptable workaround or not. Thus, I'm explicitly requesting someone from core to weight in. CC @joker-eph @matthias-springer @ftynse

Instead of linking in the MPI header file that is decided on by the pre-processor, could we make the MPI library a run-time choice? Instead of using a header file, I suggest we hardcode the ABI based on our knowledge. We can use a little python script to extract the ABI we need, but requiring the mpi.h header might not be a good idea. In the end, 90% of this PR already hardcodes the MPI API without relying on the MPI headers. I feel the cost of adding some ABI knowledge is small and the benefit of being independent of headers and in-line with MLIR-style are notable.

https://github.com/llvm/llvm-project/pull/127053