llvm dev - Sep 2017 - getelementptr

Hello,
I wonder if the getelementptr can have other successors than load, store in
some other cases when I directly print or directly return the result. every
time I would like to assign the result - it will have a load/store
successor?
So, basically the overall question is to clarify the possible successors of
getelementptr.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170901/26dee887/attachment.html>

On 1 Sep 2017, at 11:44, Anastasiya Ruzhanskaya via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Hello,
> I wonder if the getelementptr can have other successors than load, store in
some other cases when I directly print or directly return the result. every time
I would like to assign the result - it will have a load/store successor?
> So, basically the overall question is to clarify the possible successors of
getelementptr.
Any instruction that may take a pointer operand might be a user of a GEP.  For
example, consider this C function:

int x(struct S *s)
{
	y(&s->field);
}

Here, there will be a GEP to get the address of the field and then the user will
be a call (or possibly invoke) instruction.

David

Ok, thank you. I have also one question about getelementptr. In different
versions of clang I see that sometimes array[i][i] is preceded by two
getelementptr instructions and sometimes only by one - with an already
complex index.

2017-09-01 12:50 GMT+02:00 David Chisnall <David.Chisnall at
cl.cam.ac.uk>:
> On 1 Sep 2017, at 11:44, Anastasiya Ruzhanskaya via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > Hello,
> > I wonder if the getelementptr can have other successors than load,
store
> in some other cases when I directly print or directly return the result.
> every time I would like to assign the result - it will have a load/store
> successor?
> > So, basically the overall question is to clarify the possible
successors
> of getelementptr.
>
> Any instruction that may take a pointer operand might be a user of a GEP.
> For example, consider this C function:
>
> int x(struct S *s)
> {
>         y(&s->field);
> }
>
> Here, there will be a GEP to get the address of the field and then the
> user will be a call (or possibly invoke) instruction.
>
> David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170902/199b3bdd/attachment-0001.html>