[LLVMdev] How to handle size_t in front ends?

[Jonathan S. Shapiro]

On Wed, 2008-05-07 at 00:05 -0700, Chris Lattner wrote:
> On May 6, 2008, at 11:49 PM, Jonathan S. Shapiro wrote:
> Chris:
> >
> > There are other languages that specify a "word" type along these  
> > lines.
> > Would it be worth considering adding such a type to the IR, or is  
> > there
> > a reason not to do so that I am failing to see?
> 
> What would this be used for?  How is it defined?  How does arithmetic  
> work on it?

What it would be used for is emitting platform-neutral IR for languages
that require a platform-sensitive integral type. BitC, for example,
explicitly specifies all integer sizes other than word, and specifies
that word is an integral value having at least as many bits as the
native pointer type. BitC does not permit (at the source level)
inter-operation between Word and other integral types, but that can be
dealt with entirely as a restriction in the front-end.

The reason that we introduced type Word, aside from systems-level
requirements, was that the type of array and vector indices cannot be
stated without this. The index type needs to be something that can span
an arbitrary character vector. It doesn't make sense for that type to be
i32 on a 64-bit machine, but i32 isn't big enough on a 64-bit machine.
Conversely it doesn't make sense for it to be i64 on a 32-bit machine.

Meaning: on a machine having 32-bit registers, iWord is a type treated
by the IR as indistinguishable from i32. On a machine having 64 bit
registers, iWord is the a type treated by the IR as indistinguishable
from i64. Arithmetic works in the usual way. If "iWord" is "i32" on your
target, then it is acceptable in any position and condition where "i32"
would be acceptable in the IR specification. In short, iWord can be
substituted for the appropriate integral type the instant you commit to
a particular target.

In practice, I don't really think that a magic type of this sort is
necessary unless we want to have the capability for an
architecture-neutral IR. Assuming we know the target architecture, we
already know what size to emit. But it would be pleasant to be able to
emit and pickle machine-independent IR for BitC.


shap