This ensure backward compatibility on bitcode loading.
Details
Diff Detail
- Build Status
Buildable 2236 Build 2236: arc lint + arc unit
Event Timeline
llvm/lib/Bitcode/Reader/BitcodeReader.cpp | ||
---|---|---|
51 | I'd have mildly preferred doing the NFC header sorting in a separate change. | |
157 | Why are you skipping these? Would be nice to add a one-liner, unless it is patently obvious. | |
476 | I'd have named this as TBAAStripped since it really indicates if we've already stripped out TBAA metadata (and hence there is no need to check this in for newer functions). Right now this seems imperative, and it sounds like setting this to true will cause TBAA to be stripped. | |
llvm/lib/Bitcode/Reader/MetadataLoader.cpp | ||
1367 | Should this not continue (otherwise you'll drop all metadata once you've seen !tbaa)? Actually, I'd rather write this out separately as: if (I->second == LLVMContext::MD_tbaa && StripTBAA) continue; right after the if (!MD) check. | |
llvm/lib/Bitcode/Reader/MetadataLoader.h | ||
58 | End comment with period. Also, why not /// for doxygen? |
llvm/lib/Bitcode/Reader/BitcodeReader.cpp | ||
---|---|---|
51 | That was not intentional, clang-format did it for me. | |
157 | A function that is Materializable hasn't been materialized, so it does not have a body. It is not a declaration either as its body may be parsed later. Trying to iterate it results in an assertion. | |
476 | Actually it will also cause TBAA to be stripped :) | |
llvm/lib/Bitcode/Reader/MetadataLoader.cpp | ||
1367 | It is breaking out of the switch. I'll move the check above. |
llvm/lib/Bitcode/Reader/BitcodeReader.cpp | ||
---|---|---|
157 | I think this use of dropUnknownNonDebugMetadata is wrong (and so is the usage in CodeGenPrepare::stripInvariantGroupMetadata). The argument to dropUnknownNonDebugMetadata is the set of metadata IDs that are "known" and should not be dropped. All non-debug metadata *not* in that set is dropped. The reason why this works is that TBAA->getMetadataID() is an entirely different thing. It is the IDs that are used to distinguish between MDString, MDNode etc. (the subclass id, basically, which also feeds into dyn_cast etc.). Since that ID is not equal to LLVMContext::MD_tbaa, we end up dropping MD_tbaa. The right usage here is: I.setMetadata(LLVMContext::MD_tbaa, nullptr). | |
476 |
But that is not this flag is it? I thought you were dropping future TBAA by setting the flag on MetadataLoaderImpl. From what I can gather locally, if I manually bool StripTBAA = false; to bool StripTBAA = true; then I would not drop TBAA at all, and you're using this flag solely to remember if you've asked MDLoader to not load new TBAA, and so you don't have to walk instructions(F). In that sense, it isn't imperative, it just "remembers" if a certain action was done in the past. However, I'm not cognizant of the inter-relationships between these classes that you changed, so I may be missing the forest for the trees. | |
llvm/lib/Bitcode/Reader/MetadataLoader.cpp | ||
1367 | Right, but isn't it also breaking out of the innermost for? |
llvm/lib/Bitcode/Reader/BitcodeReader.cpp | ||
---|---|---|
157 | I've fixed the bad usage in CGP in https://reviews.llvm.org/rL289973 |
Address comments!
llvm/lib/Bitcode/Reader/BitcodeReader.cpp | ||
---|---|---|
157 | Uh... I took indeed example on the usage in CodeGenPrepare! | |
476 | Indeed it is redundant with the state on the MetadataLoader. I think I can remove it from here and add a getter on the MetadataLoader. You'll tell me with the next update if it helps :) | |
llvm/lib/Bitcode/Reader/MetadataLoader.cpp | ||
1367 | Right, I missed the inner for! I was looking at the break that follows a few lines below, but missed the fact that we had an enclosing for. |
lgtm
llvm/lib/Bitcode/Reader/BitcodeReader.cpp | ||
---|---|---|
159 | The checking is redundant -- you can just do I.setMetadata(LLVMContext::MD_tbaa, nullptr) unconditionally (that should not do anything if MD_tbaa was not present on the instruction). |
llvm/lib/Bitcode/Reader/BitcodeReader.cpp | ||
---|---|---|
159 | Good point. I also modified the test to check that we only strip the TBAA attachment on instructions. |
I'd have mildly preferred doing the NFC header sorting in a separate change.