This is an archive of the discontinued LLVM Phabricator instance.

[OpaquePtr] BitcodeReader: don't rely on Types derived from a Value to provide pointer structure
ClosedPublic

Authored by t.p.northover on May 31 2019, 10:13 AM.

Details

Reviewers
dblaikie
jyknight
Summary

There are a handful of places where the result type of an instruction (or ConstantExpr) can depend on one of the input operands during bitcode parsing. We are and have been removing this from bitcode generated in the future, but will still need to be able to read and upgrade old bitcode when we move to opaque pointers.

The high-level effect of this is that BitcodeReader will need to derive the needed type information more or less directly from the type records (which will still contain the full structure of pointer types for old bitcode) rather than from some particular Value's Type, which may be dramatically flattened.

The future I imagine has a BitcodeSerializationPointerType which is only ever created by BitcodeReader.cpp, and then the flattenPointerTypes would recursively convert any given type to use the PointerType on demand, and that's what would end up in Value instances. But there are other ways to do it that don't fundamentally change the structure of this patch as far as I can tell.

I tested the libLTO.dylib with these changes when self-hosting with a clang binary back to 3.6 (before the load/GEP changes) and it works fine. Before that Clang's front-end chokes on something and segfaults; probably something too new in a system header but I didn't investigate.

Diff Detail

Event Timeline

t.p.northover created this revision.May 31 2019, 10:13 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 31 2019, 10:13 AM
dblaikie accepted this revision.Jun 12 2019, 12:42 PM

I don't fully have the direction you've in mind/that this is a part of in my head - but roughly enough to give a thumbs-up here :)

This revision is now accepted and ready to land.Jun 12 2019, 12:42 PM

I don't fully have the direction you've in mind/that this is a part of in my head - but roughly enough to give a thumbs-up here :)

FWIW, I took a look back when Tim posted this and it looked roughly good to me too.

t.p.northover closed this revision.Jun 27 2019, 7:50 AM

Thanks. Should be committed as r364550.