[llvm-dev] Using "opaque pointers" right now?

[David Blaikie via llvm-dev]

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>