[LLVMdev] Suggestion: Support union types in IR

Andrew Lenharth andrewl at lenharth.org
Tue May 12 05:44:30 PDT 2009

On Fri, May 8, 2009 at 12:25 PM, Chris Lattner <clattner at apple.com> wrote:
> On May 5, 2009, at 9:55 PM, Talin wrote:
>> 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.
> What do you intend to do with this size?  At some point you have to do
> an operation that depends on the size.  The problem with adding an
> intptr_t is that at some point you have to convert it to another
> datatype, and you don't know whether it will be a zext/trunc/bitcast
> etc.

You may want to feed it back into GEP.  If size() for the container is
the first step in calculating a pivot point for qsort, then as long as
GEP takes in intptr_t you are set.  In fact, if intptr_t existed, it
would be all a GEP or malloc had to take and those instructions
wouldn't need the current bi-version approach (nor any other thing
that takes a size, like the mem* intrinsics).  I would go so far as to
say that ptr->int and int->ptr cases should only be possible to an
intptr type, and then the target knowledge which currently is embedded
in the ptr cast is embedded in the int cast if you need to cast to a
known size.


More information about the llvm-dev mailing list