Commit Graph

9 Commits

Author SHA1 Message Date
Stephen Neuendorffer dd046c9612 Revert "[MLIR] Add support for libMLIR.so"
This reverts commit e17d9c11d4.
It breaks the build.
2020-02-29 11:09:21 -08:00
Valentin Churavy e17d9c11d4 [MLIR] Add support for libMLIR.so
Putting this up mainly for discussion on
how this should be done. I am interested in MLIR from
the Julia side and we currently have a strong preference
to dynamically linking against the LLVM shared library,
and would like to have a MLIR shared library.

This patch adds a new cmake function add_mlir_library()
which accumulates a list of targets to be compiled into
libMLIR.so.  Note that not all libraries make sense to
be compiled into libMLIR.so.  In particular, we want
to avoid libraries which primarily exist to support
certain tools (such as mlir-opt and mlir-cpu-runner).

Note that the resulting libMLIR.so depends on LLVM, but
does not contain any LLVM components.  As a result, it
is necessary to link with libLLVM.so to avoid linkage
errors. So, libMLIR.so requires LLVM_BUILD_LLVM_DYLIB=on

FYI, Currently it appears that LLVM_LINK_LLVM_DYLIB is broken
because mlir-tblgen is linked against libLLVM.so and
and independent LLVM components.

Previous version of this patch broke depencies on TableGen
targets.  This appears to be because it compiled all
libraries to OBJECT libraries (probably because cmake
is generating different target names).  Avoiding object
libraries results in correct dependencies.

(updated by Stephen Neuendorffer)

Differential Revision: https://reviews.llvm.org/D73130
2020-02-29 10:47:27 -08:00
Stephen Neuendorffer c6f3fc4999 Revert "[MLIR] Add support for libMLIR.so"
This reverts commit 1246e86716.
2020-02-28 12:17:39 -08:00
Valentin Churavy 1246e86716 [MLIR] Add support for libMLIR.so
Putting this up mainly for discussion on
how this should be done. I am interested in MLIR from
the Julia side and we currently have a strong preference
to dynamically linking against the LLVM shared library,
and would like to have a MLIR shared library.

This patch adds a new cmake function add_mlir_library()
which accumulates a list of targets to be compiled into
libMLIR.so.  Note that not all libraries make sense to
be compiled into libMLIR.so.  In particular, we want
to avoid libraries which primarily exist to support
certain tools (such as mlir-opt and mlir-cpu-runner).

Note that the resulting libMLIR.so depends on LLVM, but
does not contain any LLVM components.  As a result, it
is necessary to link with libLLVM.so to avoid linkage
errors. So, libMLIR.so requires LLVM_BUILD_LLVM_DYLIB=on

FYI, Currently it appears that LLVM_LINK_LLVM_DYLIB is broken
because mlir-tblgen is linked against libLLVM.so and
and independent LLVM components

(updated by Stephen Neuendorffer)

Differential Revision: https://reviews.llvm.org/D73130
2020-02-28 11:35:19 -08:00
Stephen Neuendorffer c07fb9e016 [MLIR] Refactor library handling for conversions.
Collect a list of conversion libraries in cmake, so we don't have to
list these explicitly in most binaries.

Differential Revision: https://reviews.llvm.org/D75222
2020-02-28 11:35:17 -08:00
Stephen Neuendorffer 5869552821 [MLIR] Refactor handling of dialect libraries
Instead of creating extra libraries we don't really need, collect a
list of all dialects and use that instead.

Differential Revision: https://reviews.llvm.org/D75221
2020-02-28 11:35:16 -08:00
Stephen Neuendorffer d7cbef2714 [MLIR] Fixes for shared library dependencies.
Summary:

This patch is a step towards enabling BUILD_SHARED_LIBS=on, which
builds most libraries as DLLs instead of statically linked libraries.
The main effect of this is that incremental build times are greatly
reduced, since usually only one library need be relinked in response
to isolated code changes.

The bulk of this patch is fixing incorrect usage of cmake, where library
dependencies are listed under add_dependencies rather than under
target_link_libraries or under the LINK_LIBS tag.  Correct usage should be
like this:

add_dependencies(MLIRfoo MLIRfooIncGen)
target_link_libraries(MLIRfoo MLIRlib1 MLIRlib2)

A separate issue is that in cmake, dependencies between static libraries
are automatically included in dependencies.  In the above example, if MLIBlib1
depends on MLIRlib2, then it is sufficient to have only MLIRlib1 in the
target_link_libraries.  When compiling with shared libraries, it is necessary
to have both MLIRlib1 and MLIRlib2 specified if MLIRfoo uses symbols from both.

Reviewers: mravishankar, antiagainst, nicolasvasilache, vchuravy, inouehrs, mehdi_amini, jdoerfert

Reviewed By: nicolasvasilache, mehdi_amini

Subscribers: Joonsoo, merge_guards_bot, jholewinski, mgorny, mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, csigg, arpith-jacob, mgester, lucyrfox, herhut, aartbik, liufengdb, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D73653
2020-02-04 08:56:37 -08:00
Jacques Pienaar e47b561398 [mlir] Revert MSVC specific part of whole_archive_link
Revert the MSVC specific parts in whole_archive_link to previous form to
potentially address https://bugs.llvm.org/show_bug.cgi?id=44660.
2020-01-25 09:56:04 -08:00
Mehdi Amini 5114d55dde [Flang] add some cmake code to allow for out-of-tree building of MLIR and LLVM
Differential Revision: https://reviews.llvm.org/D72418
2020-01-22 17:43:15 +00:00