On Sat, Nov 23, 2013 at 1:57 AM, Wei Mi <w...@google.com> wrote:
> On Fri, Nov 22, 2013 at 9:21 AM, Wei Mi <w...@google.com> wrote:
>>> I think the problem can be showed by below example:
>>> struct tag
>>> {
>>> int a[10];
>>> int b;
>>> };
>>> struct tag s;
>>> int foo(int len)
>>> {
>>> int i = 0;
>>> int sum = 0;
>>> for (i = 0; i < len; i++)
>>> sum += barr (&s.a[i]);
>>>
>>> return sum;
>>> }
>>> The dump before IVOPT is like:
>>>
>>> <bb 4>:
>>> # i_16 = PHI <i_10(6), 0(3)>
>>> # sum_17 = PHI <sum_9(6), 0(3)>
>>> _6 = &s.a[i_16];
>>> _8 = barr (_6);
>>> sum_9 = _8 + sum_17;
>>> i_10 = i_16 + 1;
>>> if (len_5(D) > i_10)
>>> goto <bb 6>;
>>> else
>>> goto <bb 5>;
>>>
>>> <bb 5>:
>>> # sum_11 = PHI <sum_9(4)>
>>> goto <bb 7>;
>>>
>>> <bb 6>:
>>> goto <bb 4>;
>>>
>>> The iv use of _6 in bar(_6) is actually an memory address and it can
>>> be computed efficiently for some targets. For now IVOPT only honors
>>> address type iv uses appeared in memory access, so this patch is
>>> trying to handle this kind of address iv which is outside of memory
>>> access just the same. Please correct me if I am wrong.
>>
>> Yes, that is correct.
>>
>
> Sorry, to make a correction here. That is not my patch is doing. The
> patch is not handling normal address exprs, but those exprs could be
> expressed as mem accesses after builtins expand.
>
Thanks for explanation, now I understand why these builtins are special.
Thanks,
bin
--
Best Regards.
