This is an archive of the discontinued LLVM Phabricator instance.

[mlir] translate types between MLIR LLVM dialect and LLVM IR
ClosedPublic

Authored by ftynse on Jul 31 2020, 3:50 AM.

Details

Summary

With new LLVM dialect type modeling, the dialect types no longer wrap LLVM IR
types. Therefore, they need to be translated to and from LLVM IR during export
and import. Introduce the relevant functionality for translating types. It is
currently exercised by an ad-hoc type translation roundtripping test that will
be subsumed by the actual translation test when the type system transition is
complete.

Depends On D84339

Diff Detail

Event Timeline

ftynse created this revision.Jul 31 2020, 3:50 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 31 2020, 3:50 AM
ftynse requested review of this revision.Jul 31 2020, 3:50 AM
herhut accepted this revision.Jul 31 2020, 7:49 AM

It is a bit sad the we have two dynamic dispatch implementations but I guess there is no way around it. A LLVMTypeNew::translate overloaded method would be great :)

mlir/test/Target/llvmir-types.mlir
217

Is there a way to test that mutually-b leads to the same type object?

This revision is now accepted and ready to land.Jul 31 2020, 7:49 AM
rriddle added inline comments.Jul 31 2020, 11:43 AM
mlir/lib/Target/LLVMIR/TypeTranslation.cpp
205

If the name of the translation functions were the same, you could use a generic lambda:

LLVM::LLVMTypeNew translated = llvm::TypeSwitch<llvm::Type *, LLVM::LLVMTypeNew>(type)
.Case<llvm::ArrayType, llvm::FunctionType, ...>([this](auto *type) {
  return this->translateType(type);
}
ftynse marked an inline comment as done.Aug 3 2020, 9:00 AM

It is a bit sad the we have two dynamic dispatch implementations but I guess there is no way around it. A LLVMTypeNew::translate overloaded method would be great :)

I refactored TypeTo/FromLLVMIRTranslator to have the overload, following the suggestion from River, it's private for now but we can make it public if the need arises. I don't want it to be on LLVMTypeNew, because it will require LLVMTypeNew to become aware of the LLVM IR internals and locking, which is exactly what I want to avoid with the new type modeling.

mlir/test/Target/llvmir-types.mlir
217

It's tested in the type declarations above (line 194-195), type uses only have the name of the type.

ftynse updated this revision to Diff 282643.Aug 3 2020, 9:15 AM

Address review and rebase

ftynse updated this revision to Diff 282662.Aug 3 2020, 10:03 AM

Fix typo in Cmake

ftynse updated this revision to Diff 282842.Aug 4 2020, 2:42 AM

Rebase and fix Windows build