[PATCH] D62742: [OpaquePtr] BitcodeReader: don't rely on Types derived from a Value to provide pointer structure
Tim Northover via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri May 31 10:13:48 PDT 2019
t.p.northover created this revision.
t.p.northover added reviewers: dblaikie, jyknight.
Herald added subscribers: jfb, dexonsmith, hiraditya, mehdi_amini, mcrosier.
Herald added a project: LLVM.
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.
rG LLVM Github Monorepo
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 44024 bytes
Desc: not available
More information about the llvm-commits