[PATCH] D77027: Make BitVector::operator== return false for different-sized vectors

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Apr 7 11:23:21 PDT 2020


dblaikie added a comment.

Thanks for this!

In D77027#1966204 <https://reviews.llvm.org/D77027#1966204>, @bmoody wrote:

> I've reviewed all the uses of BitVector::operator==/!= in llvm and clang by renaming the functions and checking all the code that failed to compile.  As far as I can tell, all uses should be either unaffected by the change, or will be more correct with the change applied.
>
>  ---
>
> llvm/include/llvm/Analysis/TargetLibraryInfo.h:
>
>   bool areInlineCompatible(const TargetLibraryInfo &CalleeTLI,
>                            bool AllowCallerSuperset) const {
>     if (!AllowCallerSuperset)
>       return OverrideAsUnavailable == CalleeTLI.OverrideAsUnavailable;
>     BitVector B = OverrideAsUnavailable;
>     B |= CalleeTLI.OverrideAsUnavailable;
>     // We can inline if the union of the caller and callee's nobuiltin
>     // attributes is no stricter than the caller's nobuiltin attributes.
>     return B == OverrideAsUnavailable;
>   }
>   
>
> Not affected by the proposed change - all vectors have constant size NumLibFuncs.
>
>  ---
>
> llvm/lib/CodeGen/RegisterClassInfo.cpp:
>
>   const BitVector &RR = MF->getRegInfo().getReservedRegs();
>   if (Reserved.size() != RR.size() || RR != Reserved) {
>     Update = true;
>     Reserved = RR;
>   }
>   
>
> Not affected by the proposed change - code has an explicit size check.


Could you migrate this code to use just the operator in this change since the size check will now be redundant?

>  ---
> 
> llvm/lib/Transforms/Coroutines/CoroFrame.cpp:
> 
>   Changed |= (S.Kills != SavedKills) || (S.Consumes != SavedConsumes);
>    
>   if (S.Kills != SavedKills) {
>     LLVM_DEBUG(dbgs() << "\nblock " << I << " follower " << SI->getName()
>                       << "\n");
>     LLVM_DEBUG(dump("S.Kills", S.Kills));
>     LLVM_DEBUG(dump("SavedKills", SavedKills));
>   }
>   if (S.Consumes != SavedConsumes) {
>     LLVM_DEBUG(dbgs() << "\nblock " << I << " follower " << SI << "\n");
>     LLVM_DEBUG(dump("S.Consume", S.Consumes));
>     LLVM_DEBUG(dump("SavedCons", SavedConsumes));
>   }
>    
> 
> Not affected by the proposed change - all the vectors in this code have the same size. They're initialised above, in the same function:
> 
>   // Initialize every block so that it consumes itself
>   for (size_t I = 0; I < N; ++I) {
>     auto &B = Block[I];
>     B.Consumes.resize(N);
>     B.Kills.resize(N);
>     B.Consumes.set(I);
>   }
>    
> 
> 
> 
>  ---
> 
> llvm/tools/llvm-exegesis/lib/MCInstrDescView.cpp:
> 
>   const BitVector *BitVectorCache::getUnique(BitVector &&BV) const {
>     for (const auto &Entry : Cache)
>       if (*Entry == BV)
>         return Entry.get();
>     Cache.push_back(std::make_unique<BitVector>());
>     auto &Entry = Cache.back();
>     Entry->swap(BV);
>     return Entry.get();
>   }
>    
> 
> Looks like the proposed change will fix a (probably latent) bug in this code. Currently it seems like this function could return a pointer to a BitVector with a different size than the one that was passed in, which would be surprising.

I think this code is probably fine - all the BitVectors start by being initialized from "emptyRegisters" (pre-initialized with the necessary size) in exegesis::Instruction::create, I think.

> 
> 
>  ---
> 
> llvm/include/llvm/ADT/PackedVector.h:
> 
>   bool operator==(const PackedVector &RHS) const {
>     return Bits == RHS.Bits;
>   }
>    
>   bool operator!=(const PackedVector &RHS) const {
>     return Bits != RHS.Bits;
>   }
>    
> 
> I think this is another latent bug.  PackedVector::operator== doesn't appear to be used anywhere.

Is it tested? Might be worth leaving a FIXME of "hey, this is untested code".



================
Comment at: llvm/include/llvm/ADT/BitVector.h:542
-
-    // Verify that any extra words are all zeros.
-    if (i != ThisWords) {
----------------
Hmm - looking at this more closely (ie: I'm now actually looking at the code rather than just the commentary/discussion) this code makes me a bit uncomfortable - looks pretty intentionally designed to support potentially equal comparison of differently lengthed BitVectors. Is there any history of how/when this was added/potentially used?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77027/new/

https://reviews.llvm.org/D77027





More information about the llvm-commits mailing list