This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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]

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



--
Best Regards.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]