On Fri, Nov 22, 2013 at 10:11 PM, Zdenek Dvorak
<rakd...@iuuk.mff.cuni.cz> wrote:
> Hi,
>
>> >> > If a pointer typed use is plainly value passed to a func call, it is
>> >> > not an address use, right? But as you said, x86 lea may help here.
>> >>
>> >> But that's what you are matching ... (well, for builtins you know
>> >> will expand that to a memory reference).
>> >>
>> >> What I dislike in the patch is the special-casing of some builtins
>> >> via a target hook. I'd rather say treat all internal functions and
>> >> all target builtins that way. Or simply all addresses.
>> >
>> > unless the architecture has lea-type instruction to compute the address,
>> > computing say b+4*i incurs some cost, while if mem[b+4*i] is accessed, the
>> > computation is for free. Thus, it does not make sense to treat the address
>> > computations the same way as memory references (or to treat all functions
>> > the same way as builtins which translate to memory references),
>>
>> I understand that, but I think the patch tries to improve code generation
>> not by changing the set of IVs used (thus adjust cost considerations)
>> but by changing the way it rewrites certain address uses.
>
> actually, the costs are adjusted in the patch -- the address calculations
> for the handled builtins are recorded as USE_ADDRESS (not as
> USE_NONLINEAR_EXPR),
> so that their costs are calculated in the same way as for memory references,
>
> Zdenek
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.
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).
2) If I understand it right, this is an issue not only limited to
builtin functions, it stands for normal function calls too, right?
Thanks,
bin
--
Best Regards.
On Fri, Nov 22, 2013 at 10:11 PM, Zdenek Dvorak
<rakd...@iuuk.mff.cuni.cz> wrote:
> Hi,
>
>> >> > If a pointer typed use is plainly value passed to a func call, it is
>> >> > not an address use, right? But as you said, x86 lea may help here.
>> >>
>> >> But that's what you are matching ... (well, for builtins you know
>> >> will expand that to a memory reference).
>> >>
>> >> What I dislike in the patch is the special-casing of some builtins
>> >> via a target hook. I'd rather say treat all internal functions and
>> >> all target builtins that way. Or simply all addresses.
>> >
>> > unless the architecture has lea-type instruction to compute the address,
>> > computing say b+4*i incurs some cost, while if mem[b+4*i] is accessed, the
>> > computation is for free. Thus, it does not make sense to treat the address
>> > computations the same way as memory references (or to treat all functions
>> > the same way as builtins which translate to memory references),
>>
>> I understand that, but I think the patch tries to improve code generation
>> not by changing the set of IVs used (thus adjust cost considerations)
>> but by changing the way it rewrites certain address uses.
>
> actually, the costs are adjusted in the patch -- the address calculations
> for the handled builtins are recorded as USE_ADDRESS (not as
> USE_NONLINEAR_EXPR),
> so that their costs are calculated in the same way as for memory references,
>
> Zdenek
--
Best Regards.
