llvm dev - Apr 2020 - Various Intermediate Representations. IR

On Tue, 14 Apr 2020 at 21:24, Michael Kruse <llvmdev at 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?

Kind Regards

James

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)

On Wed, Apr 15, 2020 at 3:17 AM James Courtier-Dutton via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Tue, 14 Apr 2020 at 21:24, Michael Kruse <llvmdev at
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?
>
> 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/20200415/5fde40e2/attachment.html>

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.

Kind Regards

James