[LLVMdev] Suggestion: Support union types in IR

Olivier Meurant meurant.olivier at gmail.com
Wed May 6 00:15:06 PDT 2009


The TargetData class gives you the size of the pointer. (getPointerSize and
getPointerSizeInBits).
Can it help you ?


On Wed, May 6, 2009 at 6:55 AM, Talin <viridia at gmail.com> wrote:

> Chris Lattner wrote:
> > On May 5, 2009, at 8:09 PM, Talin wrote:
> >
> >
> >> I wanted to mention, by the way, that my need/desire for this hasn't
> >> gone away :)
> >>
> >> And my wish list still includes support for something like uintptr_t
> >> - a
> >> primitive integer type that is defined to always be the same size as a
> >> pointer, however large or small that may be on different platforms.
> >> (So
> >> that the frontend doesn't need to know how big a pointer is and can
> >> generate the same IR that works on both 32-bit and 64-bit platforms.)
> >>
> >
> > Why not just use a pointer, such as i8*?
> >
> Suppose I have an STL-like container that has a 'begin' and 'end'
> pointer. Now I want to find the size() of the container. Since you
> cannot subtract pointers in LLVM IR, you have to cast them to an integer
> type first. But what integer type do you cast them to? I suppose you
> could simply always cast them to i64, and hope that the backend will
> generate efficient code for the subtraction, but I have no way of
> knowing this.
>
> Now, I'm going to anticipate what I think will be your next argument,
> which is that at some point I must know the size of the result since I
> am assigning the result of size() to some interger variable eventually.
> Which is true, however, if the size of that eventual variable is smaller
> than a pointer, then I want to check it for overflow before I do the
> assignment. I don't want to just do a blind bitcast and have the top
> bits be lopped off.
>
> The problem of checking for overflow when assigning from an integer of
> unknown size to an integer of known size is left as an exercise for the
> reader.
> > -Chris
> >
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090506/6db3c5cf/attachment.html>


More information about the llvm-dev mailing list