llvm dev - Dec 2019 - Using "opaque pointers" right now?

I was looking at the talk from 2015 about opaque pointers.

Aside from using the new methods (e.g. LLVMBuildGEP2), is there any other way to
perpare for this change?

And also - is it possible to use something like opaque pointers (that is using a
single pointer type) even before the switch has been flipped in LLVM?


Christoffer
AEGIK / www.aegik.se

Hi Christoffer,

On Mon, 16 Dec 2019 at 00:03, Christoffer Lernö via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Aside from using the new methods (e.g. LLVMBuildGEP2), is there any other
way to perpare for this change?
The main one is to make sure you avoid using getElementType on
pointers. If you're writing a front-end this probably means you need
to keep your AST's representation of element types alongside LLVM
pointer Values in your own data-structures (beware, llvm::Type may not
be enough if that contains nested pointers). That lets you pass them
into the instructions that will need it (loads, GEPs, allocas etc).
> And also - is it possible to use something like opaque pointers (that is
using a single pointer type) even before the switch has been flipped in LLVM?
Not in current LLVM. I have a branch that has some work on them. I've
been meaning to upload, document and propose a real path forwards on
llvm-dev but other things have gotten in the way up to now. I think
there's quite a bit of infrastructure work just to make the bitcode
and IR layers accept opaque pointers, and after that many passes and
other components assert when they first encounter an opaque pointer.

I've not managed to fix all of those yet so I'm still a bit unsure how
things will work then, but I'd expect at least some correctness and
performance regressions to begin with. I'm hoping that work can happen
incrementally and during this phase I hope people would be able to
experiment and make sure they're ready.

Cheers.

Tim.

On Mon, Dec 16, 2019 at 1:28 AM Tim Northover via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi Christoffer,
>
> On Mon, 16 Dec 2019 at 00:03, Christoffer Lernö via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > Aside from using the new methods (e.g. LLVMBuildGEP2), is there any
> other way to perpare for this change?
>
> The main one is to make sure you avoid using getElementType on
> pointers. If you're writing a front-end this probably means you need
> to keep your AST's representation of element types alongside LLVM
> pointer Values in your own data-structures (beware, llvm::Type may not
> be enough if that contains nested pointers). That lets you pass them
> into the instructions that will need it (loads, GEPs, allocas etc).
>
> > And also - is it possible to use something like opaque pointers (that
is
> using a single pointer type) even before the switch has been flipped in
> LLVM?
>
> Not in current LLVM. I have a branch that has some work on them. I've
> been meaning to upload, document and propose a real path forwards on
> llvm-dev but other things have gotten in the way up to now. I think
> there's quite a bit of infrastructure work just to make the bitcode
> and IR layers accept opaque pointers, and after that many passes and
> other components assert when they first encounter an opaque pointer.
>
Awesome :) (I think last I really looked at this my next hurdle was going
to be intrinsics that are sort of name-mangled overloaded based on
parameter types, but I can see how adding a new opaque pointer type as part
of a migration makes sense (maybe that's what John McCall suggested after I
was a fair way down the original migration path... maybe, I forget) to
exist in parallel and move things over to)

> I've not managed to fix all of those yet so I'm still a bit unsure
how
> things will work then, but I'd expect at least some correctness and
> performance regressions to begin with. I'm hoping that work can happen
> incrementally and during this phase I hope people would be able to
> experiment and make sure they're ready.
>
> Cheers.
>
> Tim.
> _______________________________________________
> 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/20191216/b1ae3c6a/attachment.html>

> pointers. If you're writing a front-end this probably means you need
> to keep your AST's representation of element types alongside LLVM
> pointer Values in your own data-structures
Yeah, that’s no problem - the type is needed for signed/unsigned integer
distinctions anyway. There’s no getting around having one’s own type hierarchy.
>> And also - is it possible to use something like opaque pointers (that
is using a single pointer type) even before the switch has been flipped in LLVM?
> 
> Not in current LLVM. I have a branch that has some work on them.
Anything I could have a look at to get a sneak peek?
> I’ve been meaning to upload, document and propose a real path forwards on
> llvm-dev but other things have gotten in the way up to now. I think
> there's quite a bit of infrastructure work just to make the bitcode
> and IR layers accept opaque pointers, and after that many passes and
> other components assert when they first encounter an opaque pointer.
Interesting. Is there a timeline for this or is it more of a ”it’s done when
it’s done”?


/Christoffer