[llvm-dev] getelementptr

[Anastasiya Ruzhanskaya via llvm-dev]

I think the last question about getelementptr, is why:
 else if (isa<Constant>(*GEP.idx_begin()) &&
               cast<Constant>(*GEP.idx_begin())->isNullValue() &&
               Src->getNumOperands() != 1) {
      // Otherwise we can do the fold if the first index of the GEP is a
zero

why we can fold only if the first argument is zero? What wrong will happen
if I will have first offset 1?

2017-09-03 8:06 GMT+02:00 Anastasiya Ruzhanskaya <
anastasiya.ruzhanskaya at frtk.ru>:

> I also looked at some examples and I noticed that these too function
> declaration result in totally different code:
> #define N 100
> void pivot (int x[], int a[][N], int n, int k) {
>
> void pivot (int *x, int **a, int n, int k) {
>
> To access element if array a, in the second case I have to do a load at first , after getelementptr of the first dimension and then make getelementptr again :
>
> getelementptr->load->getelementptr.
>
> In the first case there is only one getelementptr on the two dimensions simultaneously(getelementptr with three arguments) : getelementptr->load.
>
> What is the difference?
>
>
> 2017-09-03 7:18 GMT+02:00 Anastasiya Ruzhanskaya <
> anastasiya.ruzhanskaya at frtk.ru>:
>
>> So, I am trying to do smth like this. Basically, we are developing are
>> own hls tool for fpga based on llvm. Getelementptr is not representable in
>> hardware (as far as I understand, I am here a person , who deals with llvm
>> mostly). The easiest case will be to derive the index and pass it to memory
>> controller, which is connected to load and store instructions. However,
>> when there is a getelementptr for structures - the things become too
>> complicated to derive the offset (index). So, by now I am trying to
>> understand what are rules for getelementptr in code, what can be it's
>> successors , what can be it's predecessors in order to come to another
>> solution.
>>
>> 2017-09-02 23:31 GMT+02:00 Daniel Berlin <dberlin at dberlin.org>:
>>
>>> No.
>>> It would be helpful to understand what you are trying to accomplish
>>> overall, which may help people give you details about the best way to
>>> accomplish it.
>>> For example, if you are trying to understand or recover array indexes
>>> from GEP's,  that is non-trivial.
>>>
>>>
>>> On Sat, Sep 2, 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>:
>>>>
>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170903/fc955f77/attachment.html>