[PATCH] D72542: [Flang] add a band-aid to support the creation of mutually recursive types when lowering to LLVM IR

[Eric Schweitz via Phabricator via llvm-commits]

schweitz marked an inline comment as done.
schweitz added inline comments.


================
Comment at: mlir/test/Dialect/LLVMIR/roundtrip.mlir:223
+// XXXCHECK: llvm.func @recursive_type(!llvm<"%a = type { %a* }">)
+//llvm.func @recursive_type(!llvm<"%a = type { %a* }">)
----------------
ftynse wrote:
> schweitz wrote:
> > ftynse wrote:
> > > Could we have test for translating such types to LLVM? Normally, we should be able to parse the recursive type and see it after translation. Somewhere in test/Target/llvmir.mlir would be the right place.
> > The title of this diff was meant to reflect the transitory nature of this patch. Parser work needs to be done to finish this. It is still undecided the exact nature of that parser work, as far as I understand.
> > 
> > This patch was being driven by merging the MLIR dependence into the F18/Flang project which was itself trying to be merged into the LLVM monorepo. It looks like all of these merges are on hold for now, so the urgency to have some sort of solution has been alleviated.
> > 
> > We still need real support for recursive-types in the LLVM-IR dialect of MLIR at some point (to support Fortran in our case).
> > 
> Even if it is a transient state, having a self-contained (i.e. not depending on f18) test is a way to demonstrate this state is useful for something and at least partially correct.
It's problematic to build a functional test without a parser that can read the input. Since there is no way to read the recursive type from the IR file, we can't build it that way, nor can we output anything.

When driving this from C++ code, we can build a recursive type in memory and the pretty-printer *does* emit the LLVM type.



CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72542/new/

https://reviews.llvm.org/D72542