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

[Tim Northover via llvm-dev]

On Tue, 17 Dec 2019 at 08:22, Christoffer Lernö <christoffer at aegik.com> wrote:
> > 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.

Excellent! Clang actually struggles there despite also having
signed/unsigned types, though it's kind of improving.

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

Sure, I've rebased it and spruced it up very slightly (it's still very
much developer's own tree rather than anything I'd want to be judged
for). There should be two branches at
https://github.com/TNorthover/llvm-project:

  * "opaque-ptr" has an LLVM that's mostly functional, but if you want
you can create opaque pointer types (via hand-written IR or hopefully
a front-end) to see how they fare.
  * "opaque-ptr-always" has a patch that forces every pointer
everywhere to be opaque (useful for flushing out issues). It has
thousands of test failures and hundreds of assertions in just "ninja
check". Though with only tens of root causes as far as I can tell.

Not that I think there's any reason to do so, but don't start relying
on hashes or commits. I am extremely likely to force push there.

If you're hand-writing IR I chose "pN" as the representation for the
type. I've attached an example .ll file I was working with to test
instructions one-by-one, but you might see something like:

    define i32 @load_element_42(p0 %in) {
      %addr = getelementptr i32, p0 %in, i32 42
      %val = load i32, p0 %in
      ret i32 %val
    }

The patches so far seem to have been in a few categories:

  * Adapt the the serialization to cope with opaque pointers (textual
IR <-> in-memory <-> bitcode).
  * Relax assertions and other checks so that individual instructions
can exist without a pointer element type.
  * Remove deprecated CreateCall, CreateLoad and CreateGEP functions
(ones that derive type from the Value input).
  * Fix passes & targets etc to (essentially) remove all uses of
getElementType, one by one.

That order is roughly how I'd see them being committed to LLVM (if
everyone agrees with me), not how they are in the branch. It should
allow for incremental testing of each phase, I think.

> Interesting. Is there a timeline for this or is it more of a ”it’s done when it’s done”?

I think a timeline is well off; we'll have to wait to see what the
long tail looks like. Also, since we're forcing changes on front-ends,
there has to be at least a release cycle between announcement and code
becoming invalid for any of that to happen. But we ought to be able to
do that in parallel with development.

I'm hoping to get some consensus for a path forwards when I can gather
my thoughts into an llvm-dev message though. Now that it's all pretty
fresh in my memory again, it's probably a good time.

Cheers.


Tim.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: opaque.ll
Type: application/octet-stream
Size: 1538 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191218/c13b869e/attachment.obj>