llvm dev - May 2008 - [LLVMdev] How to handle size_t in front ends?

On Wed, 2008-05-07 at 16:09 -0700, Chris Lattner wrote:
> On Wed, 7 May 2008, Jonathan S. Shapiro wrote:
> >>
> >> i64 should be big enough for this.  Just use i64.
> >
> > On a 32-bit platform, doesn't one want to use i32?
> 
> Why?  What is wrong with i64?
On its face, the problem is that it doesn't fit in a native register...
or is there something here that I am failing to understand?

On Wed, 7 May 2008, Jonathan S. Shapiro wrote:
> On Wed, 2008-05-07 at 16:09 -0700, Chris Lattner wrote:
>> On Wed, 7 May 2008, Jonathan S. Shapiro wrote:
>>>>
>>>> i64 should be big enough for this.  Just use i64.
>>>
>>> On a 32-bit platform, doesn't one want to use i32?
>>
>> Why?  What is wrong with i64?
>
> On its face, the problem is that it doesn't fit in a native register...
> or is there something here that I am failing to understand?
The code generator deletes dead upper parts.  For example:

int test(long long a, long long b) {
   return a+b;  // 64-bit add, taking low 32-bits
}

compiles to a single add, even on x86-32:

_test:
 	movl	12(%esp), %eax
 	addl	4(%esp), %eax
 	ret

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/

On Wed, 2008-05-07 at 18:07 -0700, Chris Lattner wrote:
> On Wed, 7 May 2008, Jonathan S. Shapiro wrote:
> > On Wed, 2008-05-07 at 16:09 -0700, Chris Lattner wrote:
> >> On Wed, 7 May 2008, Jonathan S. Shapiro wrote:
> >>>>
> >>>> i64 should be big enough for this.  Just use i64.
> >>>
> >>> On a 32-bit platform, doesn't one want to use i32?
> >>
> >> Why?  What is wrong with i64?
> >
> > On its face, the problem is that it doesn't fit in a native
register...
> > or is there something here that I am failing to understand?
> 
> The code generator deletes dead upper parts...
I understand the reduction that you are doing. I like it, but this
reduction often is not possible for vector accesses (the case at hand)
when the index argument to the "vector get" primitive is defined as an
i64. Even when the operations can be compiled away, the reduction does
not address the difference in storage overhead and the implications for
structure layout differences when iWord fields appear within structs.

Your reduction will work wonderfully on simple for loops that iterate
over vectors -- even, with care, in doacross situations -- but it won't
help at all when vector indices are stored into variables for later use
elsewhere in the program (that is: the array cursor pattern). In
critical systems codes, this pattern is very common, which is why I'm
concerned about it.


shap