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

2013-04-28 Thread Bin.Cheng
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))?

2013-04-28 Thread Bin.Cheng
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))?

2013-04-28 Thread Richard Biener
"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

2013-04-28 Thread gccadmin
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

2013-04-28 Thread Shin Eon-seong

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