This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Builtins handling in IVOPT
- From: Wei Mi <wmi at google dot com>
- To: "Bin.Cheng" <amker dot cheng at gmail dot com>
- Cc: Zdenek Dvorak <rakdver at iuuk dot mff dot cuni dot cz>, Richard Biener <richard dot guenther at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, David Li <davidxl at google dot com>
- Date: Fri, 22 Nov 2013 09:57:51 -0800
- Subject: Re: [PATCH] Builtins handling in IVOPT
- Authentication-results: sourceware.org; auth=none
- References: <CA+4CFy7_1JO7r3eq8TWzotR1L6oGKkecZx24OvBd8yeXKcshWQ at mail dot gmail dot com> <CAFiYyc192S2FxNiaeOd6tCvOi0XBfi2arCd4Obf+sckkfwja3g at mail dot gmail dot com> <CA+4CFy6Qcsd1H=zm=LXGJ1c=E_aTcDU-WXAn0eXHmqBAC3z6PA at mail dot gmail dot com> <0ec94f32-fbb3-4bc0-ba03-cdd8d217c545 at email dot android dot com> <CA+4CFy5D96nJv9WUhiqhzcsc7-xmvirZrWQyTAqEtjj2KQSCVw at mail dot gmail dot com> <6fcfa72b-fb3d-464c-9bce-c4641d498c14 at email dot android dot com> <CA+4CFy6G7veBucfUBc53PG-Mvh8HJihtZMHc+dsX8_QX9WjTAw at mail dot gmail dot com> <CAFiYyc2hkS0tYujcupoxwGdgRSxABcF_2d5r+6N=VsSA7JSxjw at mail dot gmail dot com> <20131122111914 dot GA30986 at kam dot mff dot cuni dot cz> <CAFiYyc2u5z43ioG0QX_9XVeZKBZ3+x9e9YbMZ8GFnGCX07nygw at mail dot gmail dot com> <20131122141128 dot GA18286 at kam dot mff dot cuni dot cz> <CAHFci2_XaEWAnAw_0=gURZE_O9LZQ0FDijd+cF-fk9r+Sx_K1w at mail dot gmail dot com> <CA+4CFy5phnGKeAMPZjYqNOGQ2rsfZeUnsu7aPdEvyFU9KPYw6A at mail dot gmail dot com>
On Fri, Nov 22, 2013 at 9:21 AM, Wei Mi <wmi@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.
>>
>> 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.