[LLVMdev] the getelementptr noop problem

[Chris Lattner]

> so i confess i'm still not clear on what the first index into
> getelementptr is all about.

I'm sure you're not the only one.  :)  This is one of the wierdest aspects
of LLVM to the unaccustomed.

> it makes perfect sense for an example like
> getelementptr %mystruct * %reg100
> to just return a %mystruct * equivalent to %reg100.
>
> it does *not* make sense to me that
> getelementptr %mystruct * %reg100, uint 0
> should act the same.  for look, what this speaks of to me is indexing the
> first element in an array.  if we are careful to cast it back to %mystruct
> *, then it should *work*, although it is useless.  but, i would not expect

Ok, think of this as:

Foo = &Reg[0];

Which is a noop if reg is a pointer...

> int ** x = <some array>;
> int ** y = x[0];
>
> to work unless we cast x[0] as an int **, and not the int * it would
> otherwise return.

Remember that it is returning a POINTER to the indexed value... so it's
&x[0]...

> moreover, if this were something that we could really count on acting as a
> noop, then we could have
>
> %reg101 = getelementptr %mystruct * %reg100, uint 0
> %reg102 = getelementptr %mystruct * %reg101, uint 0
> ... and so on, and not make a difference.  which to me seems the same as

That's true...

> %regn   = getelementptr %mystruct * %reg100, uint 0, uint 0, ...
> which *ought to be* indexing deep into some array.

Yes, unfortunately, getelementpointer is not compositional, which only
adds to the confusion.  :(

> so -- what exactly does the first indexing uint 0 do?  is it safe to leave
> it off?  do all good getelementptrs have it, so that i should assert that
> there is one?

The LLVM language ref gives a decent example of what it's used for:
http://llvm.cs.uiuc.edu/docs/LangRef.html#i_getelementptr

For this MP though, you really don't need to understand it.  Basically if
the first index is NOT a long 0, some array stuff is going on, and your
pass cannot handle it anyway.  Your safety checker should consider any
allocas used this way (as in any allocas with non-long 0 first indexes) as
not safe to transform, thus leaving them alone.

-Chris

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