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.

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

This reverts commit b0f7f6f78d050cc89b31c87fb48744989145af60.

Causes test failures: https://lab.llvm.org/buildbot#builders/61/builds/24879

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.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D123425

Its number of optional parameters has grown too large,
which makes adding new optional parameters quite a chore.

Fix this by using an options struct.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D120380