[LLVMdev] Union Type

[Chris Lattner]

On Fri, 19 Dec 2003, Reid Spencer wrote:
> > example, would this really solve the problem?  You could, for example,
> > write a program that pushes a pointer, then pops off an int.  This would
> > work fine on a 32-bit target, but obviously not on a 64-bit one.
>
> Stack mistakes resulting from the Stacker source, as in this case, are
> the problem of the Stacker programmer, not the compiler. Its possible
> but not valid to do the operation you suggested. If you push a pointer,
> you should pop it with something that expects a pointer and knows how to
> use it correctly.

Ok, so in this case, pushing a 2-word pointer on a 64-bit target would be
acceptable.  If we can just figure out how to...

> The issue in my mind is by how much one increments the stack index when
> a pointer is pushed. The answer in the current implementation is always
> "1". That works fine on a 32-bit platform because the stack array
> element is 32-bits (int). Both ints and pointers fit in 32-bits and
> incrementing the index by 1 moves the index by 32-bits. When you move to
> a machine that has 64-bit pointers and 32-bit ints, then this needs to
> change so that the index is incremented by 2 when a pointer is pushed.

Ok, good point.  Well there is a fairly ugly way in LLVM of computing the
size of a type: through the getelementptr instruction.  It works basically
like the traditional implementation of 'offsetof' macro in C.  If you want
to get the size of 'sbyte*' for example:

%tmp = getelementptr sbyte** null, long 1    ; tmp = (sbyte**)null+1
%size = cast sbyte** %tmp to int

Of course, in LLVM, these can both be folded together into two constant
expressions, so they will not need to be evaluated at run-time.

> > Since stacker doesn't "protect" its end users (in a memory safety sense),
> > I think that a 64-bit stacker target should just push 64-bit pointers like
> > it would push 64 bit integer types: just take up two slots.  Is there
> > anything wrong with this approach?
>
> Nope. In fact, what I think I'll implement is just a 64-bit stack. That
> is, the base type of the stack will be "long" instead of int. LLVM
> assures me that this is 64-bits. It is large enough to hold a pointer on
> all supported platforms. By doing this, I don't have to mess with the
> index increment, its still always 1. This also has the added advantage
> of increasing the range of integer values and better supporting floating
> point should that become a future feature.

That would work, but the problem is that it wastes quite a bit of space.
The advantage of that is that it would be much less sensitive to user
errors like pushing a pointer, then popping off an integer though...

> > Using a union for the stacker stack on
> > a 64-bit machine would waste a ton of space when integers are pushed.
>
> Why? The union would still be 64-bits long. If we increase the integer
> value size to 64-bits it won't be a waste, it'll be a "feature" :)

Heh, I was assuming that most integers would be 32-bits in size.  :)

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/