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

[Richard Biener]

"Bin.Cheng" <amker.cheng@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.

Richard.

>On Sun, Apr 28, 2013 at 3:15 PM, Bin.Cheng <amker.cheng@gmail.com>
>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.