[PATCH] D118694: [Bitcode] Add partial support for opaque pointer auto-upgrade
David Blaikie via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Feb 1 09:19:08 PST 2022
dblaikie added inline comments.
================
Comment at: llvm/lib/Bitcode/Reader/BitcodeReader.cpp:1185-1190
+ if (Context.supportsTypedPointers()) {
+ Type *Ty = TypeList[ID];
+ if (Ty->isPointerTy())
+ return Ty->getNonOpaquePointerElementType();
+ return nullptr;
+ }
----------------
Would it be reasonable/possible to always use the `ElementTypeList` even when typed pointers are supported? (frontload changes somewhat) - maybe with typed pointer support this could be an assert that the type in `ElementTypeList` matches the non-opaque pointer type?
(oh, I guess since this support is currently incomplete that's not possible, but would be possible when the support is complete but before opaque pointers are enabled by default? I guess it could still be an assert today in the case where `ElementTypeList` is available, maybe?)
================
Comment at: llvm/lib/Bitcode/Reader/BitcodeReader.cpp:5036-5037
+ Ty = getElementTypeByID(Record[0]);
+ if (!Ty)
+ return error("Missing element type for old-style alloca");
}
----------------
I wonder if these sort of checks could be asserts? I realize they are dynamically reachable, but they're also not intended to be reached by end users (only by LLVM developers during this migration)... I guess it's weird either way. Either we have asserts that are dynamically reachable, or we have error paths that are untested... I don't feel great about either of those, but either seem like acceptable tradeoffs during the transition.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D118694/new/
https://reviews.llvm.org/D118694
More information about the llvm-commits
mailing list