[LLVMdev] Two important changes to the getelementptr instruction

[Reid Spencer]

On Sun, 2004-04-04 at 22:05, Chris Lattner wrote:
> .....
> 
> The big
> distinction is that you can index with variables in arrays and pointers,
> but only constant integers in structures.

Doh! That is a big distinction. Thanks for reminding me.

> ...
> > If that's the case, then why restrict structure indexes to uint and not
> > make it "any integer type"? This might further reduce casting and
> > generalizes the programming model.
> 
> The idea is that structure indices must be *constants*.  As such, it
> doesn't really matter what type we make them, as long as there is enough
> "addressing space" to represent enough fields.  Allowing structure fields
> to be "any type" is possible, but wouldn't give us anything: uint 7 means
> the same thing as sbyte 7.
> 
> The disadvantage of allowing any integer type for the structure index is
> that we have to encode the integer type used in the bytecode file, which
> takes space.  Right now the type of the index is implicitly encoded into
> the bytecode file based on what operand of the getelementptr it is.
> Another advantage is that clients of the LLVM IR can assume that all
> structure indexes are instances of ConstantUInt, which simplifies
> construction and modification of the IR a bit.
> 

Wow, its just as if you've thought this stuff through :)

You are, of course, right. Its simpler for language implementers to just
deal with ConstantUInt and simpler for LLVM too.  Since they have to be
constants, there's no point allowing other types.  When I made that
suggestion I was think any integer expression could be used to index a
structure field but that doesn't make sense, as you've pointed out.

Thanks for satisfying my curiosity.

Reid.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040405/a295d8c0/attachment.sig>