On Thu, May 16, 2013 at 7:21 PM, Bin.Cheng <amker.ch...@gmail.com> wrote: > 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. 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.
