[llvm-dev] Using "opaque pointers" right now?
Nicolai Hähnle via llvm-dev
llvm-dev at lists.llvm.org
Wed Dec 18 07:29:49 PST 2019
On Wed, Dec 18, 2019 at 2:17 PM Tim Northover via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> 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.
I happened to look at this a while ago, and it seems to me that
removing the deprecated Create* functions and getPointerElementType as
early as possible is a good idea since it cannot be done mechanically,
is often quite painful (introducing architectural concerns even!), and
as long as those functions exist (without explicitly being labelled
with LLVM_ATTRIBUTE_DEPRECATED), there's a risk of new uses of them
> > 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.
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.
More information about the llvm-dev