Page MenuHomePhabricator

[MLIR] Move from add_llvm_library to add_llvm_component_library
AbandonedPublic

Authored by stephenneuendorffer on Jan 13 2020, 12:02 AM.

Details

Summary

This results in most MLIR libraries being linked into libLLVM.so

Event Timeline

nicolasvasilache resigned from this revision.Jan 16 2020, 5:42 AM

I am not familiar enough with cmake to comment here, removing myself as a blocker.

Are there other LLVM subproject who inject themselves into the global llvm shared library? Should we have a libMLIR.so instead?

Are there other LLVM subproject who inject themselves into the global llvm shared library? Should we have a libMLIR.so instead?

Yes I think a libMLIR.so is the right choice, the only reason to go the other way would be if LLVM starts depending on MLIR. A libMLIR.so is a clearer separation and even LTO is split out into its own library.

Are there other LLVM subproject who inject themselves into the global llvm shared library? Should we have a libMLIR.so instead?

Yes I think a libMLIR.so is the right choice, the only reason to go the other way would be if LLVM starts depending on MLIR. A libMLIR.so is a clearer separation and even LTO is split out into its own library.

OK. It looks like to deal with the whole_archive_link line for mlir-opt, this will have to be aware of which libraries are linked into the shared library, so the cmake machinery mostly needs to be there to handle this anyway.

Yes I think a libMLIR.so is the right choice, the only reason to go the other way would be if LLVM starts depending on MLIR.

This isn't a possibility to exclude entirely though, it'd be better if we don't add hurdles now to this future possibility.

LTO is split out into its own library.

I believe that this is a different situation: the LTO library is always built as a shared library because it a linker plugin. It also exposes a very specific API for this purpose: it is a different product entirely.
The LLVM shared library on the other hand is an alternative to the static libraries.