[LLVMdev] Two important changes to the getelementptr instruction

[Reid Spencer]

Hi Chris,

Congrats on getting this taken care of finally.  I know its something
you've wanted to do since 1.0.

I have one question.  How does LLVM disambiguate between a uint used for
a structure and a uint used for an array?  My assumption is that LLVM is
aware of the type of the thing being indexed all the way through the
dereference so it doesn't really matter what index type is being used.
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.

Mostly just curious ...

Reid.

On Sun, 2004-04-04 at 19:00, Chris Lattner wrote:
> Hi all,
> 
> I just checked in a series of patches that makes some substantial changes
> to the LLVM getelementptr instruction.  In particular, in LLVM 1.2 and
> earlier, the getelementptr instruction required index operands for
> structure types to be 'ubyte' constants and index operands for sequential
> types to be 'long' values.  This had several problems, most notably that
> it was impossible to represent a structure with more than 256 fields, and
> performance for 32-bit targets suffered.
> 
> Now in CVS, structure indices are required to be 'uint' constants, which
> permits structures with up to 2^32 elements.  Sequential type indices are
> allowed to be any int, uint, long, and ulong values.  This is documented
> in the LLVM language reference here:
> http://llvm.cs.uiuc.edu/docs/LangRef.html#i_getelementptr
> 
> This change required modifying the encoding of getelementptr instruction
> in bytecode files, so LLVM 1.3 bytecode files won't be readable by LLVM
> 1.2 and earlier.  LLVM .ll files and .bc files from earlier releases, as
> usual, will work fine with the newer version.  In particular, we will
> always support .ll files that use ubyte indexes for structure types, as
> the parser auto-upgrades them to uint indexes.
> 
> This change fixes the following bugs:
> http://llvm.cs.uiuc.edu/PR82
> http://llvm.cs.uiuc.edu/PR309
> 
> It also results in cleaner and simpler LLVM code, allowing many integer
> casts that were present for array indexes to go away.  Though the encoding
> of getelementptr instructions is slightly less efficient than before
> (because we have to store what type the various sequential type operands
> are), the reduction in cast instructions actually results in a bytecode
> size reduction of about 1%.
> 
> If you have any questions about this change, please let me know,
> 
> -Chris


_______________________
Reid Spencer
President & CTO
eXtensible Systems, Inc.
rspencer at x10sys.com
-------------- 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/20040404/cafef1f3/attachment.sig>