One step towards enabling the use of Swift C++ interop for MLIR is allowing MLIR to be build with clang modules enabled, which is already supported in LLVM via the LLVM_ENABLE_MODULES CMake flag and the creation of a module map similar to LLVM’s module map.

Clang modules seem to have benefits outside of enabling Swift bindings, the most interesting of which seems to be faster compilation. Currently, MLIR fails to build with LLVM_ENABLE_MODULES, is there a reason MLIR hasn’t adopted this yet? I’m currently working on a PR to get this working, does anyone have any concerns about supporting modules in MLIR?

Once this works I think we would need a bot that ensures this doesn’t regress otherwise it’s quite likely to break again.

Great point, could this be as simple as updating the current CI to use LLVM_ENABLE_MODULES? As I understand it building with modules is more strict than building without, though I wouldn’t be surprised if there could be some subtle issues with header ordering and such.

I don’t know what the tradeoffs are but what you are suggesting matches the mental model I have on this.

What do the other LLVM bots do?

It depends what you mean by “the current CI”.

The easiest thing would be to pick an existing configuration that represents what you normally build and just add the new flag to a new builder. This means you don’t remove the previous configuration and test what you’ll normally build, so that others don’t break your stuff while it’s not default.

As for a more global approach to enable modules to wider LLVM, which I think we want eventually, would be doing that on a larger scale until we’re confident enough stuff pass, then we flip the switch (to default modules on) and fix the remaining issues, and remove the (now redundant) flag from all builds (or leave some left overs with modules=off so we can fix later).

1 Like