[LLVMdev] Two important changes to the getelementptr instruction

Chris Lattner sabre at nondot.org
Sun Apr 4 20:57:01 PDT 2004


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

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/




More information about the llvm-dev mailing list