Diego Novillo - Re: PATCH: CALL_EXPR representation part 3/9 (middle-end stuff) (original) (raw)

This is the mail archive of the gcc-patches@gcc.gnu.orgmailing list for the GCC project.

• From: Diego Novillo
• To: Sandra Loosemore
• Cc: GCC Patches , Brooks Moses , Lee Millward
• Date: Mon, 12 Feb 2007 09:14:53 -0500
• Subject: Re: PATCH: CALL_EXPR representation part 3/9 (middle-end stuff)
• References: <45CDE396.2030804@codesourcery.com>

• /* When walking an array, compute the length and store it in a

•    local variable before walking the array elements, instead of

•    recomputing the length expression each time through the loop.

•    This is necessary to handle the new CALL_EXPR representation

•    where the length is stored in the first array element,

•    because otherwise that operand can get overwritten on the

•    first iteration.  */

s/to handle the new CALL_EXPR representation/to handle CALL_EXPRs/In a couple of years, the term "new CALL_EXPR representation" will be meaningless.

--- 1294,1300 ---- label1 = build1 (LABEL_EXPR, void_type_node, label_decl1); stmt1 = unshare_expr (stmt); call = get_call_expr_in (stmt1); ! CALL_EXPR_ARG2 (call) = value;

I don't like this shorthand. I would much rather see CALL_EXPR_ARG (call, 2) than CALL_EXPR_ARG2 (call).

*************** chrec_contains_symbols_defined_in_loop (
*** 386,411 ****
return false;
}
! switch (TREE_CODE_LENGTH (TREE_CODE (chrec)))
! {
! case 3:
! if (chrec_contains_symbols_defined_in_loop (TREE_OPERAND (chrec, 2), ! loop_nb))
! return true;
! ! case 2:
! if (chrec_contains_symbols_defined_in_loop (TREE_OPERAND (chrec, 1), ! loop_nb))
! return true;
! ! case 1:
! if (chrec_contains_symbols_defined_in_loop (TREE_OPERAND (chrec, 0), ! loop_nb))
! return true;
! ! default:
! return false;
! }
}
/* Return true when PHI is a loop-phi-node. */
--- 388,399 ----
return false;
}
! n = TREE_OPERAND_LENGTH (chrec);
! for (i = 0; i < n; i++)
! if (chrec_contains_symbols_defined_in_loop (TREE_OPERAND (chrec, i), ! loop_nb))
! return true;
! return false;
}

No. You are changing the semantics of this code. The code specifically asks for 1, 2 and 3.
I still haven't finished going through the rest of the patch, but this is what jumped at me on an initial scan.Looks like a very nice cleanup. Kudos.

• Follow-Ups:
  • Re: PATCH: CALL_EXPR representation part 3/9 (middle-end stuff)
    * From: Sandra Loosemore
• References:
  • PATCH: CALL_EXPR representation part 3/9 (middle-end stuff)
    * From: Sandra Loosemore