prepare_decl_rtl in tree-ssa-loop-ivopts.c doesn't work with (ADDR_EXPR (ARRAY_REF))?
Hi, Currently tree-ssa-loop-ivopts.c doesn't calculate addr_expr's cost, while uses target_spill_cost instead, as in function force_expr_to_var_cost. When I experimented with ivopts by calling computation_cost to calculate cost of ADDR_EXPR, I encountered assert failure in expand_expr_addr_expr_1, because: 0) The failure comes with (ADDR_EXPR (ARRAY_REF (local_var_decl))); 1) computation_cost calls walk_tree/prepare_decl_rtl to prepare RTX_REG for variables in ADDR_EXPR, which is the local_var_decl; 2) computation_cost calls expand_expr to do the expanding work. 3) function expand_expr_addr_expr_1 returns the RTX_REG as the result of expanding, which violates the assertion "gcc_assert (MEM_P (result))". The corresponding code in expand_expr_addr_expr_1 is like : default: /* If the object is a DECL, then expand it for its rtl. Don't bypass expand_expr, as that can have various side effects; LABEL_DECLs for example, may not have their DECL_RTL set yet. Expand the rtl of CONSTRUCTORs too, which should yield a memory reference for the constructor's contents. Assume language specific tree nodes can be expanded in some interesting way. */ gcc_assert (TREE_CODE (exp) < LAST_AND_UNUSED_TREE_CODE); if (DECL_P (exp) || TREE_CODE (exp) == CONSTRUCTOR || TREE_CODE (exp) == COMPOUND_LITERAL_EXPR) { result = expand_expr (exp, target, tmode, modifier == EXPAND_INITIALIZER ? EXPAND_INITIALIZER : EXPAND_CONST_ADDRESS); /* If the DECL isn't in memory, then the DECL wasn't properly marked TREE_ADDRESSABLE, which will be either a front-end or a tree optimizer bug. */ if (TREE_ADDRESSABLE (exp) && ! MEM_P (result) && ! targetm.calls.allocate_stack_slots_for_args()) { error ("local frame unavailable (naked function?)"); return result; } else gcc_assert (MEM_P (result)); result = XEXP (result, 0); /* ??? Is this needed anymore? */ if (DECL_P (exp)) TREE_USED (exp) = 1; if (modifier != EXPAND_INITIALIZER && modifier != EXPAND_CONST_ADDRESS && modifier != EXPAND_SUM) result = force_operand (result, target); return result; } So the question is Is it as expected that cost of ADDR_EXPR cannot be calculated by computation_cost? Or the assertion is because of immature computation_cost/prepare_decl_rtl? I am not sure whether I described the problem clearly, please feel free to ask for more information. Thanks for your patience. -- Best Regards.
Re: prepare_decl_rtl in tree-ssa-loop-ivopts.c doesn't work with (ADDR_EXPR (ARRAY_REF))?
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? On Sun, Apr 28, 2013 at 3:15 PM, Bin.Cheng wrote: > Hi, > Currently tree-ssa-loop-ivopts.c doesn't calculate addr_expr's cost, > while uses target_spill_cost instead, as in function > force_expr_to_var_cost. When I experimented with ivopts by calling > computation_cost to calculate cost of ADDR_EXPR, I encountered assert > failure in expand_expr_addr_expr_1, because: > 0) The failure comes with (ADDR_EXPR (ARRAY_REF (local_var_decl))); > 1) computation_cost calls walk_tree/prepare_decl_rtl to prepare > RTX_REG for variables in ADDR_EXPR, which is the local_var_decl; > 2) computation_cost calls expand_expr to do the expanding work. > 3) function expand_expr_addr_expr_1 returns the RTX_REG as the result > of expanding, which violates the assertion "gcc_assert (MEM_P > (result))". The corresponding code in expand_expr_addr_expr_1 is like > : > > default: > /* If the object is a DECL, then expand it for its rtl. Don't bypass > expand_expr, as that can have various side effects; LABEL_DECLs for > example, may not have their DECL_RTL set yet. Expand the rtl of > CONSTRUCTORs too, which should yield a memory reference for the > constructor's contents. Assume language specific tree nodes can > be expanded in some interesting way. */ > gcc_assert (TREE_CODE (exp) < LAST_AND_UNUSED_TREE_CODE); > if (DECL_P (exp) > || TREE_CODE (exp) == CONSTRUCTOR > || TREE_CODE (exp) == COMPOUND_LITERAL_EXPR) > { > result = expand_expr (exp, target, tmode, > modifier == EXPAND_INITIALIZER > ? EXPAND_INITIALIZER : EXPAND_CONST_ADDRESS); > > /* If the DECL isn't in memory, then the DECL wasn't properly > marked TREE_ADDRESSABLE, which will be either a front-end > or a tree optimizer bug. */ > > if (TREE_ADDRESSABLE (exp) > && ! MEM_P (result) > && ! targetm.calls.allocate_stack_slots_for_args()) > { > error ("local frame unavailable (naked function?)"); > return result; > } > else > gcc_assert (MEM_P (result)); > result = XEXP (result, 0); > > /* ??? Is this needed anymore? */ > if (DECL_P (exp)) > TREE_USED (exp) = 1; > > if (modifier != EXPAND_INITIALIZER > && modifier != EXPAND_CONST_ADDRESS > && modifier != EXPAND_SUM) > result = force_operand (result, target); > return result; > } > > So the question is > Is it as expected that cost of ADDR_EXPR cannot be calculated by > computation_cost? Or the assertion is because of immature > computation_cost/prepare_decl_rtl? > > I am not sure whether I described the problem clearly, please feel > free to ask for more information. Thanks for your patience. > > -- > Best Regards. -- Best Regards.
Re: prepare_decl_rtl in tree-ssa-loop-ivopts.c doesn't work with (ADDR_EXPR (ARRAY_REF))?
"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. Richard. >On Sun, Apr 28, 2013 at 3:15 PM, Bin.Cheng >wrote: >> Hi, >> Currently tree-ssa-loop-ivopts.c doesn't calculate addr_expr's cost, >> while uses target_spill_cost instead, as in function >> force_expr_to_var_cost. When I experimented with ivopts by calling >> computation_cost to calculate cost of ADDR_EXPR, I encountered assert >> failure in expand_expr_addr_expr_1, because: >> 0) The failure comes with (ADDR_EXPR (ARRAY_REF (local_var_decl))); >> 1) computation_cost calls walk_tree/prepare_decl_rtl to prepare >> RTX_REG for variables in ADDR_EXPR, which is the local_var_decl; >> 2) computation_cost calls expand_expr to do the expanding work. >> 3) function expand_expr_addr_expr_1 returns the RTX_REG as the result >> of expanding, which violates the assertion "gcc_assert (MEM_P >> (result))". The corresponding code in expand_expr_addr_expr_1 is like >> : >> >> default: >> /* If the object is a DECL, then expand it for its rtl. Don't >bypass >> expand_expr, as that can have various side effects; LABEL_DECLs >for >> example, may not have their DECL_RTL set yet. Expand the rtl of >> CONSTRUCTORs too, which should yield a memory reference for the >> constructor's contents. Assume language specific tree nodes can >> be expanded in some interesting way. */ >> gcc_assert (TREE_CODE (exp) < LAST_AND_UNUSED_TREE_CODE); >> if (DECL_P (exp) >> || TREE_CODE (exp) == CONSTRUCTOR >> || TREE_CODE (exp) == COMPOUND_LITERAL_EXPR) >> { >> result = expand_expr (exp, target, tmode, >> modifier == EXPAND_INITIALIZER >> ? EXPAND_INITIALIZER : EXPAND_CONST_ADDRESS); >> >> /* If the DECL isn't in memory, then the DECL wasn't properly >> marked TREE_ADDRESSABLE, which will be either a front-end >> or a tree optimizer bug. */ >> >> if (TREE_ADDRESSABLE (exp) >> && ! MEM_P (result) >> && ! targetm.calls.allocate_stack_slots_for_args()) >> { >> error ("local frame unavailable (naked function?)"); >> return result; >> } >> else >> gcc_assert (MEM_P (result)); >> result = XEXP (result, 0); >> >> /* ??? Is this needed anymore? */ >> if (DECL_P (exp)) >> TREE_USED (exp) = 1; >> >> if (modifier != EXPAND_INITIALIZER >> && modifier != EXPAND_CONST_ADDRESS >> && modifier != EXPAND_SUM) >> result = force_operand (result, target); >> return result; >> } >> >> So the question is >> Is it as expected that cost of ADDR_EXPR cannot be calculated by >> computation_cost? Or the assertion is because of immature >> computation_cost/prepare_decl_rtl? >> >> I am not sure whether I described the problem clearly, please feel >> free to ask for more information. Thanks for your patience. >> >> -- >> Best Regards.
gcc-4.9-20130428 is now available
Snapshot gcc-4.9-20130428 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20130428/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 198380 You'll find: gcc-4.9-20130428.tar.bz2 Complete GCC MD5=60afae302480c23bd63ed4b1ddc6dbd1 SHA1=9584be7f6d72471322f31e0ca4a15239e119b00b Diffs from 4.9-20130421 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.9 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.
Re: Proposition
Greetings from South Korea I have a proposition for you to the tune of Fifty Million EUR, if interested, kindly reply for specifics Regards, Shin Eon-seong