This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: prepare_decl_rtl in tree-ssa-loop-ivopts.c doesn't work with (ADDR_EXPR (ARRAY_REF))?
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: "Bin.Cheng" <amker dot cheng at gmail dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Thu, 16 May 2013 14:11:31 +0200
- Subject: Re: prepare_decl_rtl in tree-ssa-loop-ivopts.c doesn't work with (ADDR_EXPR (ARRAY_REF))?
- References: <CAHFci29paoGQKwfc=sGo_EcQU4kR1XPh2xzXfmS-qVk8+-sTYg at mail dot gmail dot com> <CAHFci2_jEna_eYGQYuJyOR0i2drf-6ZN5co+9k6T2wyU7cEsUw at mail dot gmail dot com> <1241d650-2bc3-4a58-9db0-569dd086a08b at email dot android dot com> <CAHFci29kEa151+XXMStwkzhgD5iWySChbUbojoDGwhipsBVGNQ at mail dot gmail dot com> <CAHFci2_1iVjyAZ+M+-M6ZaRuXJyoP3RGqtxNSdsMVdcuVnyd7Q at mail dot gmail dot com>
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.