rnk added inline comments.
================ Comment at: clang/lib/CodeGen/Address.h:30 + // Int portion stores lower 3 bits of the log of the alignment. + llvm::PointerIntPair<llvm::Type *, 3, unsigned> ElementType; ---------------- dblaikie wrote: > nikic wrote: > > dblaikie wrote: > > > aeubanks wrote: > > > > nikic wrote: > > > > > Are we guaranteed 3 bits even on 32-bit architectures? > > > > Apparently not, a static assert fires for a 32-bit build of clang. I > > > > was assuming 3 was fine based on the PointerIntPair comments. > > > > ``` > > > > /// PointerIntPair - This class implements a pair of a pointer and small > > > > /// integer. It is designed to represent this in the space required by > > > > one > > > > /// pointer by bitmangling the integer into the low part of the > > > > pointer. This > > > > /// can only be done for small integers: typically up to 3 bits, but it > > > > depends > > > > /// on the number of bits available according to PointerLikeTypeTraits > > > > for the > > > > /// type. > > > > ``` > > > > > > > > I suppose we could have a separate 32-bit vs 64-bit implementation of > > > > `Address`, although that's not very nice. > > > You can get more spare bits by overaligning the type that you're pointing > > > to, if that's suitable/workable. We do that in a few places in LLVM for > > > this sort of reason. > > As we're storing pointers to core LLVM types here (Value and Type), I don't > > think it's possible to over-align them. > Ah, right :/ Oh well, this probably won't work without some truly squirelly hackery. We store four bits of alignment locally, and make all-zeros a sentinel value to store large alignments out of line. It's not worth it. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D117262/new/ https://reviews.llvm.org/D117262 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
