On Sun, Apr 28, 2013 at 8:15 PM, Richard Biener <richard.guent...@gmail.com> wrote: > "Bin.Cheng" <amker.ch...@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.
