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

[Bin.Cheng]

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.

Is it true, or something missed?

Thanks again.


--- Best Regards.