Whenever someone has time to work on Bug 82, we should also fix getelementptr to
take arbitrary integer operands for the array indices as well.  Requiring long
indexes for array and pointer subscripting causes performance problems in some
code.  For example, on 164.gzip, we see the following situation:

In the X86 world, we efficiently handle code like this:
%X = cast int to long
%y = gep ... long %X

... by not actually promoting X to 64 bits (we fold the cast into the
getelementptr).

However, in 164.gzip, the code input to the optimizer looks like this:

%X = cast int %x to long
%B = getelementptr int* %A, long %X
%Y = cast int %y to long
%C = getelementptr int* %B, long %Y

which the optimizer turns into:

%X = cast int %x to long
%Y = cast int %y to long
%tmp = add long %X, %Y
%C = getelementptr int* %A, long %tmp

The X86 instruction selector performs the 64-bit add, then takes the low 32-bits
of it for the pointer arithmetic.  64-bit adds are much slower than 32-bit ones,
which causes a performance problem.

This is just a placeholder bug so that this issue doesn't get forgotten.

-Chris

Mine

This is now fixed.  LLVM code can use one of int,uint,long,ulong to index into
sequential types with a getelementptr instructions.

-Chris