On Tue, 2008-05-06 at 23:18 -0700, Chris Lattner wrote:> > 1) Is there a way to declare an integer type in the IR that represents > > "an int the same size as a pointer" without specifying exactly the > > size > > of a pointer? > > No.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? shap
On May 6, 2008, at 11:49 PM, Jonathan S. Shapiro wrote:> On Tue, 2008-05-06 at 23:18 -0700, Chris Lattner wrote: >>> 1) Is there a way to declare an integer type in the IR that >>> represents >>> "an int the same size as a pointer" without specifying exactly the >>> size >>> of a pointer? >> >> No. > > 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? -Chris
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
On 2008-05-07, at 03:05, Chris Lattner wrote:> On May 6, 2008, at 11:49 PM, Jonathan S. Shapiro wrote: > >> 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?Looking up the intptr type via TargetData is not a significant issue for me, but I can see the appeal, and how its absence could constitute a significant barrier to generating portable IR (provided, of course, a portable language). Regardless, it would allow me to hardcode a good deal more codegen if the LLVM IR had an intptr type. The semantics I would imagine for an intptr type are: • Lowered to i32 or i64 for code generation. • Treated an ordinary integer for all operations except casts. • Can be the operand to ptrtoint, but not the result. • Can be the result of inttoptr, but not the operand. • Can be bitcast to an actual pointer type. • Whether sext, zext, and trunc are applicable, I could be convinced either way. It muddies the semantics of these operations. On 2008-05-07, at 12:51, Mike Stump wrote:> The word opaque comes to mind. The basic question is, do you want > people to be able to understand this stuff, or is it more like the > bitcode file, you don't care that it is unreadable?I think this is unworkable. You can't assign an opaque value to a vreg (what if it became an struct type?)—only a pointer to an opaque can be used as a vreg. Never mind the horror of calling a runtime function to perform integer arithmetic. — Gordon