[llvm-dev] Various Intermediate Representations. IR

[River Riddle via llvm-dev]

On Thu, Apr 16, 2020 at 9:59 AM David Blaikie via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
>
> 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.
>

Saying MLIR<>LLVM is sort of confusing, as it isn't clear what the
connection point is. MLIR has an LLVM dialect which is intended to model
what is in LLVM and roundtrip properly. The LLVM dialect will model what is
in LLVM, so it doesn't matter whether the pointers are opaque or not. As
LLVM moves to opaque pointers, so will the LLVM dialect in MLIR(and without
much problem). I agree with you David, we should not try to roundtrip
between a lower level IR and higher level IR if that imposes some
unnecessary constraints on either. More specifically, I don't think we
should try to enforce that the LLVM(or LLVM dialect) is required to
roundtrip between any of the other high level dialects(like standard,
affine, etc.) in MLIR. It may be interesting for some things (e.g., polly
like raising), but isn't necessarily something I would gate the design of
LLVM on.

-- River


>
>
>>
>> Kind Regards
>>
>> James
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200416/24f2048d/attachment-0001.html>