[llvm-dev] getelementptr

Sam Elliott via llvm-dev llvm-dev at lists.llvm.org
Sat Sep 2 11:12:08 PDT 2017

This thread from June: http://lists.llvm.org/pipermail/llvm-dev/2017-June/114108.html <http://lists.llvm.org/pipermail/llvm-dev/2017-June/114108.html>

this is about a pass that can split GEPs into multiple equivalent GEPs, without changing the overall meaning. Presumably the reverse operation of merging GEPs might also be a reasonable LLVM canonicalisation pass, though I don't think it is implemented at the moment. 

If anyone knows why merging two GEPs is not equivalent to performing them one after the other, I'd love to know. I suppose the `inbounds` keyword may wreak havoc with the semantics. 


> On 2 Sep 2017, at 3:53 am, Anastasiya Ruzhanskaya via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> Is there a way to set always a defined behavior here - for example that we will always one getelemntptr with complex index?
> 2017-09-02 12:53 GMT+02:00 Anastasiya Ruzhanskaya <anastasiya.ruzhanskaya at frtk.ru <mailto:anastasiya.ruzhanskaya at frtk.ru>>:
> 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 <mailto: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 <mailto: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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Archibald Sam Elliott
ashe2 at cs.washington.edu
PhD Student, PLSE Group

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170902/63620b78/attachment.html>

More information about the llvm-dev mailing list