> 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.
>
> After thought twice, I have two concerns about this:
> 1) Why can't we just enhance the nolinear use logic to handle this
> kind of iv use? It's more complicated to handle it as a normal
> address type iv, consider that IVOPT adds auto-increment candidates
> according to them, you have to deal with that in this way
> (auto-increment addressing mode can't apply to this kind of address iv
> use).
I think existing address iv use logic is enough to handle it. I am
changing it and moving the gimple change from
find_interesting_uses_stmt to rewrite_use_address in original patch.
> 2) If I understand it right, this is an issue not only limited to
> builtin functions, it stands for normal function calls too, right?
>
For builtin function, such as _mm_loadu_si128(b+4*i), it will be
expanded to an insn: MOVDQU mem[b+4*i], $xmmreg, and the computation
of b+4*i is for free. But for function call, the b+4*i will only be
used as the value of an actual, and its computation cost cannot be
avoided.
Thanks,
Wei.
