Page MenuHomePhabricator

[mlir] Introduce dialect interfaces for translation to LLVM IR

Authored by ftynse on Feb 11 2021, 6:59 AM.



The existing approach to translation to the LLVM IR relies on a single
translation supporting the base LLVM dialect, extensible through inheritance to
support intrinsic-based dialects also derived from LLVM IR such as NVVM and
AVX512. This approach does not scale well as it requires additional
translations to be created for each new intrinsic-based dialect and does not
allow them to mix in the same module, contrary to the rest of the MLIR
infrastructure. Furthermore, OpenMP translation ingrained itself into the main
translation mechanism.

Start refactoring the translation to LLVM IR to operate using dialect
interfaces. Each dialect that contains ops translatable to LLVM IR can
implement the interface for translating them, and the top-level translation
driver can operate on interfaces without knowing about specific dialects.
Furthermore, the delayed dialect registration mechanism allows one to avoid a
dependency on LLVM IR in the dialect that is translated to it by implementing
the translation as a separate library and only registering it at the client

This change introduces the new mechanism and factors out the translation of the
"main" LLVM dialect. The remaining dialects will follow suit.

Diff Detail

Event Timeline

ftynse created this revision.Feb 11 2021, 6:59 AM
ftynse requested review of this revision.Feb 11 2021, 6:59 AM

Look great! I am only concerned about registerLLVMDialectTranslation(MLIRContext&) right now, the rest LGTM.


The fact that this API won't do anything if the dialect isn't loaded does not seem right to me.

What prevents us from always doing unconditionally the addition like this?

DialectRegistry registry;
ftynse updated this revision to Diff 323244.Feb 12 2021, 1:15 AM

Address review


Good catch!

We cannot register unconditionally because if the interface is already registered on the dialect (that is, the dialect is already loaded), an attempt to register it for the second time will trigger a double-registration assertion. We should probably fix this and just ignore repeated registrations of the same interface on the same dialect, but that deserves a separate patch.

Changed the condition in this patch to add the interface if the dialect doesn't have it yet _or_ if it has not been loaded.

ftynse added inline comments.Feb 12 2021, 7:13 AM
This revision is now accepted and ready to land.Feb 12 2021, 8:09 AM
This revision was landed with ongoing or failed builds.Feb 12 2021, 8:50 AM
This revision was automatically updated to reflect the committed changes.