[PATCH] D117262: [NFC] Store Address's alignment into PointerIntPairs
Reid Kleckner via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon Jan 24 16:16:15 PST 2022
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
More information about the cfe-commits
mailing list