[llvm-dev] Various Intermediate Representations. IR

David Blaikie via llvm-dev llvm-dev at lists.llvm.org
Thu Apr 16 09:59:26 PDT 2020

On Thu, Apr 16, 2020 at 4:48 AM James Courtier-Dutton <
james.dutton at gmail.com> wrote:

> On Wed, 15 Apr 2020 at 17:28, David Blaikie <dblaikie at gmail.com> wrote:
> >
> > opaque pointers don't exist in the IR yet - the goal is to reduce the
> places that use non-opacity of pointer types already/today and then opacify
> the existing pointer type, rather than introducing an opaque pointer type &
> having it concurrently with non-opaque pointer types. (though in retrospect
> such a migration might've been worth considering and/or might still be used
> as part of the migration, I guess)
> >
> I would have thought that it would have been useful to have both
> pointer types available.
> For example, if one wished to move from an opaque pointer to MLIR, one
> would need to add passes to derive types first.
> So, having a pass that converts from opaque pointer to typed pointer
> and back again would have been useful.
> The approach you describe kind of reduces the flexibility of LLVM.
> I think LLVM IR -> MLIR and MLIR -> LLVM IR  round tripping is a useful
> goal.

The project started before MLIR existed, FWIW. Though I'm not sure it's the
right path even today & not sure MLIR is a strong motivation - but haven't
looked into it in great detail. Not sure how the presence of MLIR would
change the design of opaque pointers. Oh, I see what you mean - you mean
going forward/indefinitely keep the typed pointers and treat it as a
lowering of sorts (from typed pointers lowering to untyped pointers) - I
think that's not the direction LLVM's heading in at the moment, at least,
but perhaps in the future as/if MLIR<>LLVM become more connected that'll
change. I'd still think of LLVM as just the lower level IR without type
information on pointers, not roundtrippable.

> Kind Regards
> James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200416/f53bb061/attachment.html>

More information about the llvm-dev mailing list