[llvm-dev] PointerIntPair

[David Blaikie via llvm-dev]

On Thu, Dec 31, 2020 at 11:13 AM Paul C. Anagnostopoulos via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> The bits are orthogonal, so I think an enum makes more sense.


I'm not quite following this - the enum would be used if these two
properties are mutually exclusive, right? (ie: you can have one or the
other, but not both) - that's not what I'd describe as "orthogonal" -
orthogonal things vary independently of one another. (ie: you can have one
feature, or the other, or neither, or both) If these properties can't both
be enabled at the same time, then they're not orthogonal - they're mutually
exclusive.


> I take it from your response that you think a PointerIntPair is a fine
> thing to use.
>
> There are no alignment requirements on an X86, for example. I presume that
> compilers impose alignments anyway, but are they consistent enough to rely
> on?
>

Depends what you're pointing to - if you were pointing to a char it'll have
alignment 1 (necessary - if you had an array of characters you can't have
padding between them, so you'll have pointers with no alignment/no spare
low bits).

If you're only pointing to malloc/new'd blocks, you've got some wiggle room
imposed by the allocator. In some places LLVM code explicitly overaligns
certain types to provide more spare low bits in their pointers.


>
> At 12/31/2020 01:51 PM, Craig Topper wrote:
> >A PointerIntPair can be placed in the pointer part of another
> PointerIntPair. So you can nest them to have 2 booleans without creating an
> enum. This works because PointerIntPair always puts the bit in the highest
> bit possible leaving the low bits free to be used by another int.
> >
> >The number of bits available in a pointer depends on the alignment
> requirement of the type the pointer points to. If it’s a class/struct it
> depends on the largest alignment required by its fields. The alignof
> operator is used to check the alignment.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201231/28524088/attachment.html>