prepare_decl_rtl in tree-ssa-loop-ivopts.c doesn't work with (ADDR_EXPR (ARRAY_REF))?

[Richard Biener]

On Thu, May 16, 2013 at 1:35 PM, Bin.Cheng <amker.cheng@gmail.com> wrote:
> On Thu, May 16, 2013 at 7:21 PM, Bin.Cheng <amker.cheng@gmail.com> wrote:
>> On Sun, Apr 28, 2013 at 8:15 PM, Richard Biener
>> <richard.guenther@gmail.com> wrote:
>>> "Bin.Cheng" <amker.cheng@gmail.com> wrote:
>>>
>>>>I suspect codes in prepare_decl_rtl:
>>>>
>>>>    case VAR_DECL:
>>>>    case PARM_DECL:
>>>>    case RESULT_DECL:
>>>>      *ws = 0;
>>>>      obj = *expr_p;
>>>>
>>>>      if (DECL_RTL_SET_P (obj))
>>>>    break;
>>>>
>>>>      if (DECL_MODE (obj) == BLKmode)
>>>>    x = produce_memory_decl_rtl (obj, regno);
>>>>      else
>>>>    x = gen_raw_REG (DECL_MODE (obj), (*regno)++);
>>>>
>>>>It generates RTX_REG(regno) for an var_decl which is an array has
>>>>DECL_MODE == OImode.
>>>>
>>>>Any suggestions?
>>>
>>> Addr_expr cost should be computed by
>>> Looking at the cost for the address computation. Not by simply expanding the address_expr. Look at get_inner_reference and handle the returned base specially.
>>>
>> Sorry for missing the message and late reply.
>>
>> I think the addr_expr should be expanded in some cases, for example,
>> computing the base cost of iv candidate.
>> Considering below candidate:
>>
>> candidate 22
>>   var_before ivtmp.27
>>   var_after ivtmp.27
>>   incremented before use 1
>>   type unsigned int
>>   base (unsigned int) ((long unsigned int *) &GasmanStatAlive + 4294967292)
>>   step 4
>>   base object (void *) &GasmanStatAlive
>> Candidate 22 is related to use 1
>> candidate 23
>>   var_before ivtmp.28
>>   var_after ivtmp.28
>>   incremented after use 1
>>   type unsigned int
>>   base (unsigned int) &GasmanStatAlive
>>   step 4
>>   base object (void *) &GasmanStatAlive
>> Candidate 23 is related to use 1
>>
>> the cost of computing base_22 in loop preheader is more expensive than
>> base_23. It's not computed as an address, so expanding would be
>> necessary.
> A mistake, the base expressions are in form:
> &array[0][offset]
> &array[0][0]

Yes, computing &array[0][offset] may be more expensive than computing
&array[0][0].

Richard.

>>
>> Is it true, or something missed?
>>
>> Thanks again.
>>
>>
>> --- Best Regards.
>
>
>
> --
> Best Regards.