Apparently trying to lookup a function pointer using the C api `mlirExecutionEngineLookup` will throw an assert instead of just returning a nullptr on builds with asserts. The docs itself says it returns a nullptr when no function is found so it should be sensible to not throw an assert in this case.
Use `mlir_target_link_libraries()` to link dependencies of libraries that are not included in libMLIR, to ensure that they link to the dylib when they are used in Flang. Otherwise, they implicitly pull in all their static dependencies, effectively causing Flang binaries to simultaneously link to the dylib and to static libraries, which is never a good idea. I have only covered the libraries that are used by Flang. If you wish, I can extend this approach to all non-libMLIR libraries in MLIR, making MLIR itself also link to the dylib consistently. [v3 with more `-DBUILD_SHARED_LIBS=ON` fixes]
This reverts commit 4c6242ebf50dde0597df2bace49d534b61122496. More BUILD_SHARED_LIBS=ON regressions, sigh.
Use `mlir_target_link_libraries()` to link dependencies of libraries that are not included in libMLIR, to ensure that they link to the dylib when they are used in Flang. Otherwise, they implicitly pull in all their static dependencies, effectively causing Flang binaries to simultaneously link to the dylib and to static libraries, which is never a good idea. I have only covered the libraries that are used by Flang. If you wish, I can extend this approach to all non-libMLIR libraries in MLIR, making MLIR itself also link to the dylib consistently. [v2 with fixed `-DBUILD_SHARED_LIBS=ON` build]
This will make it easy for callers to see issues with and fix up calls to createTargetMachine after a future change to the params of TargetMachine. This matches other nearby enums. For downstream users, this should be a fairly straightforward replacement, e.g. s/CodeGenOpt::Aggressive/CodeGenOptLevel::Aggressive or s/CGFT_/CodeGenFileType::
We've observed that the MLIR Jit Engine fails when the `omp` dialect is used due to a failure to register OpenMP-related translations. This small patch addresses this issue. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D151577
LLVM commit 8b1771bd9f3 replaced JITEvaluatedSymbol with ExecutorSymbolDef.
This patch supports the processing of dialect attributes attached to top-level module-type operations during MLIR-to-LLVMIR lowering. This approach modifies the `mlir::translateModuleToLLVMIR()` function to call `ModuleTranslation::convertOperation()` on the top-level operation, after its body has been lowered. This, in turn, will get the `LLVMTranslationDialectInterface` object associated to that operation's dialect before trying to use it for lowering prior to processing dialect attributes attached to the operation. Since there are no `LLVMTranslationDialectInterface`s for the builtin and GPU dialects, which define their own module-type operations, this patch also adds and registers them. The requirement for always calling `mlir::registerBuiltinDialectTranslation()` before any translation of MLIR to LLVM IR where builtin module operations are present is introduced. The purpose of these new translation interfaces is to succeed when processing module-type operations, allowing the lowering process to continue and to prevent the introduction of failures related to not finding such interfaces. Differential Revision: https://reviews.llvm.org/D145932
Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D136334
Use the new pass manager. This also removes the ability to run arbitrary sets of passes. Not sure if this functionality is used, but it doesn't seem to be tested. No need to initialize passes outside of constructing the PassBuilder with the new pass manager. Reland: Fixed custom calls to `-lower-matrix-intrinsics` in integration tests by replacing them with `-O0 -enable-matrix`. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D123425