Re: prepare_decl_rtl in tree-ssa-loop-ivopts.c doesn't work with (ADDR_EXPR (ARRAY_REF))?
On Sun, Apr 28, 2013 at 8:15 PM, Richard Biener wrote: > "Bin.Cheng" 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.
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 wrote: > On Sun, Apr 28, 2013 at 8:15 PM, Richard Biener > wrote: >> "Bin.Cheng" 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.
Re: prepare_decl_rtl in tree-ssa-loop-ivopts.c doesn't work with (ADDR_EXPR (ARRAY_REF))?
On Thu, May 16, 2013 at 1:35 PM, Bin.Cheng wrote: > On Thu, May 16, 2013 at 7:21 PM, Bin.Cheng wrote: >> On Sun, Apr 28, 2013 at 8:15 PM, Richard Biener >> wrote: >>> "Bin.Cheng" 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.
gcc-4.8-20130516 is now available
Snapshot gcc-4.8-20130516 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20130516/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch revision 198991 You'll find: gcc-4.8-20130516.tar.bz2 Complete GCC MD5=4fe897021f123c7d6b6038388800b804 SHA1=8e2300a4b470638b1481168a10eb4a410c57f59c Diffs from 4.8-20130509 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
