llvm dev - Sep 2002 - [LLVMdev] the getelementptr noop problem

By request, I've renamed lib/CodeGen/PreSelection to lib/CodeGen/PreOpts
(admittedly this was my choice :-), and the corresponding archive from
preselect to preopt.  If you see linker errors saying preselect.o is not
found, this is the reason.  This shouldn't happen if you update your entire
tree at once.

--Vikram

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

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

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.

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

%regn   = getelementptr %mystruct * %reg100, uint 0, uint 0, ...

which *ought to be* indexing deep into some array.

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?

thanks a lot for your help!

lee

<pre>

         +------+
       +-+     o+---\ /
    +--+  The        *-
   ++   Hamster  +--/ \
   >-------------<
   this living hand, now warm and capable
   of earnest grasping, would, if it were cold
   and in the icy silence of the tomb,
   so haunt thy days and chill thy dreaming nights
   that thou wouldst wish thine own heart dry of blood
   so in my veins red life might stream again,
   and thou be conscience-calmed -- see here it is --
   i hold it towards you.

   : john keats

</pre>

> 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/