+llvmdev, so this gets more eyes.
These points make sense to me too. In LTO, at least, sharing constants
and metadata in the context seems mostly to work against us.
I'm less aware of the tradeoffs re: the opaque pointer type, but your
brain dump is compelling. I'd be interested in whether anyone thinks
the loss of type safety there is important.
As probably the primary person to work on SROA and related passes in the
last few years that deal with pointer types, I can say that there is in
fact no type safety at all. There is just the illusion of type safety. We
would lose absolutely nothing from this.
*nod* That's been my (more limited) experience as well.
From: "Duncan P. N. Exon Smith" <dexonsmith@apple.com>
To: "Rafael Espíndola" <rafael.espindola@gmail.com>
Cc: "llvm-commits" <llvm-commits@cs.uiuc.edu>, "LLVM Developers Mailing List" <llvmdev@cs.uiuc.edu>
Sent: Thursday, December 4, 2014 12:44:39 AM
Subject: Re: Brain dump on type merging+llvmdev, so this gets more eyes.
These points make sense to me too. In LTO, at least, sharing
constants
and metadata in the context seems mostly to work against us.I'm less aware of the tradeoffs re: the opaque pointer type, but your
brain dump is compelling. I'd be interested in whether anyone thinks
the loss of type safety there is important.>
> Just want to go on record that:
>
> 1) I completely agree that constants, types, and metadata should
> all be module owned. It makes so much sense. This becomes
> tremendously more appealing when (not if!) we make datalayout
> required and frontend-provided. Because then all of these things
> have deterministic always-available access to it, etc. Goodness.
> Pure goodness.
>
> 2) I'm 100% behind moving to an opaque pointer type. Combined with
> mandatory datalayout, lots of nice things become possible. If we
> can trivially move back to structural type identity, I'm all for
> that. But I would do it in steps -- first get the opaque pointer,
> then try to improve type merging, etc.
+1 -- We don't need types on pointers -- they don't convey any information to the optimizer. FWIW, it would not surprise me if the elimination of all of the unnecessary pointer bitcasts produces measurable compile-time savings.
-Hal
Indeed.
I'm actually interested in looking at this if no one else gets to it first.
(for me, it's after the pass manager at the least) If someone else is able
to hack on this though, it would be awesome. I think it'll actually help
LTO quite a lot by reducing the footprint of the IR.
+1 -- We don't need types on pointers -- they don't convey any
information to the optimizer. FWIW, it would not surprise me if the
elimination of all of the unnecessary pointer bitcasts produces measurable
compile-time savings.Indeed.
I'm actually interested in looking at this if no one else gets to it
first. (for me, it's after the pass manager at the least) If someone else
is able to hack on this though, it would be awesome. I think it'll actually
help LTO quite a lot by reducing the footprint of the IR.
This sounds potentially like the sort of monkey work I could do/dabble in -
might chat with you more about it to see if I'm figuring that correctly
before diving in.
A couple of comments on the thread so far: - Semantically, I have no objection to the removal of the type from the pointer. I agree that this gets us very little and gives a deceptive appearance of type safety where there is none. The only strong distinction between pointer types is via address spaces; as long as that’s preserved, I have no objection. - From a readability perspective, typed pointers do actually help a lot. Looking at the IR and figuring out what a particular pointer describes would be far harder without them. If we do move to a typeless pointer, I would argue in favor of having the types still be present, but make it legal to cast between pointer types without a bitcast. (i.e. all pointer ‘names’ refer to a single underlying type) - This is a large enough change in the IR that a true proposal should be sent to the mailing list & given a week or two to propagate before any work is done.