[llvm-dev] Various Intermediate Representations. IR

[James Courtier-Dutton via llvm-dev]

Hi,

I am looking for an IR that is similar to LLVM IR, with its SSA form,
module->function->block->instruction etc.
But, I wish a much reduced type model.
I wish only three types:
1) An Integer of various bit-widths.
2) A pointer, but a pointer that does not need to point to a known
type. A sort of "pointer to unknown type".
3) Floats of various varieties.

For example, if we were using a pointer to step through an array of
32bit integers.
We would use: pointer = pointer + 4; (I.e. step over 4 octets at a time)

Is anyone aware of such an IR, or is there some way for trick LLVM IR
into only using the above 2 types?
IR already does (1) and (3). It does not seem to be able to do (2).

Kind Regards

James
_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

[Michael Kruse via llvm-dev]

Currently, LLVM often uses the *i8 type (pointer to char) to represent
a pointer to some not-specified type. We are also working on replacing
the pointer-to-type pointer types by a single pointer type without a
specific pointee-type. Look for "opaque pointer" on llvm-dev and the
repository commits.

Michael

Am Di., 14. Apr. 2020 um 15:06 Uhr schrieb James Courtier-Dutton via
llvm-dev <llvm...@lists.llvm.org>:

[Johannes Doerfert via llvm-dev]

People are actually working on 2) (for a while now). Progress was made
but I'm unsure where we are. If you search for "llvm opaque pointers"
you find the original LLVM-Dev talk, mailing list discussions, and
various patch reviews. I guess one way of achieving what you need is to
accelerate the transition in LLVM-IR ;)

Cheers,
  Johannes

[James Courtier-Dutton via llvm-dev]

On Tue, 14 Apr 2020 at 21:24, Michael Kruse <llv...@meinersbur.de> wrote:
>
> Currently, LLVM often uses the *i8 type (pointer to char) to represent
> a pointer to some not-specified type. We are also working on replacing
> the pointer-to-type pointer types by a single pointer type without a
> specific pointee-type. Look for "opaque pointer" on llvm-dev and the
> repository commits.
>

Hi Michael,
Thank you for your reply.

Does the LLVM IRBuilder currently allow adding an opaque pointer to a
LLVM .bc file?
Even if it does not compile, just being able to add it, would be helpful.
I could then run my own experimental passes against it.

Does using opaque pointers, adversely affect alias analysis?

[David Blaikie via llvm-dev]

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)

[James Courtier-Dutton via llvm-dev]

On Wed, 15 Apr 2020 at 17:28, David Blaikie <dbla...@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.

[David Blaikie via llvm-dev]

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

On Wed, 15 Apr 2020 at 17:28, David Blaikie <dbla...@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

[River Riddle via llvm-dev]

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