Aldy Hernandez - Re: [PATCH] PR30391: GIMPLE_MODIFY_STMT vs. middle-end (original) (raw)

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

• From: Aldy Hernandez
• To: Roger Sayle
• Cc: gcc-patches at gcc dot gnu dot org, dnovillo at redhat dot com
• Date: Mon, 12 Feb 2007 16:06:29 -0400
• Subject: Re: [PATCH] PR30391: GIMPLE_MODIFY_STMT vs. middle-end
• References: <9748.68.35.10.103.1170648498.squirrel@mail.eyesopen.com>

merge of the tuples branch. The underlying cause is that we're constructing special GIMPLE_MODIFY_STMT nodes (which don't have a type and don't use the regular TREE_OPERAND mechanism) and allowing them to be used as operands in middle-end expressions. Unfortunately, the tree expression handling mechanism in much of the middle-end assumes all nodes are fairly regular, and use TREE_CODE, TREE_TYPE, TREE_OPERAND etc... to inspect them. Alas when the new minimal GIMPLE_MODIFY_STMTs creep into such

The idea was to have separate folders for tuples and non tuples. For now, what I have been doing is having fold handle GIMPLE_MODIFY_STMTs as well.

See note at the top of fold-const.c:

Note: Since the folders get called on non-gimple code as well as gimple code, we need to handle GIMPLE tuples as well as their corresponding tree equivalents.

hence the proposal below is to rename build2_gimple to instead be build_gimple_stmt which implicitly builds a GIMPLE_MODIFY_STMT and need

This shouldn't just handle gimple_stmt's, as this will be used for other upcoming tuples that will be implemented.

The attached patch fixes the ICEs in all three PRs. Can someone verify that the programs behave as expected? With the PR code fragments, I can only verify that the ICEs are cured.

Aldy

* fold-const.c (operand_equal_p): Use GENERIC_TREE_TYPE when
appropriate.
(operand_equal_for_comparison_p): Same.

Index: fold-const.c

--- fold-const.c (revision 121726) +++ fold-const.c (working copy) @@ -2574,12 +2574,14 @@ operand_equal_p (tree arg0, tree arg1, u /* If both types don't have the same signedness, then we can't consider them equal. We must check this before the STRIP_NOPS calls because they may change the signedness of the arguments. */

• if (TYPE_UNSIGNED (TREE_TYPE (arg0)) != TYPE_UNSIGNED (TREE_TYPE (arg1)))

• if (TYPE_UNSIGNED (GENERIC_TREE_TYPE (arg0))

•  != TYPE_UNSIGNED (GENERIC_TREE_TYPE (arg1)))

  return 0;

  /* If both types don't have the same precision, then it is not safe to strip NOPs. */

• if (TYPE_PRECISION (TREE_TYPE (arg0)) != TYPE_PRECISION (TREE_TYPE (arg1)))

• if (TYPE_PRECISION (GENERIC_TREE_TYPE (arg0))

•  != TYPE_PRECISION (GENERIC_TREE_TYPE (arg1)))

  return 0;

  STRIP_NOPS (arg0);

@@ -2604,9 +2606,10 @@ operand_equal_p (tree arg0, tree arg1, u if (TREE_CODE (arg0) != TREE_CODE (arg1) /* This is needed for conversions and for COMPONENT_REF. Might as well play it safe and always test this. */

•  || TREE_CODE (TREE_TYPE (arg0)) == ERROR_MARK

•  || TREE_CODE (TREE_TYPE (arg1)) == ERROR_MARK

•  || TYPE_MODE (TREE_TYPE (arg0)) != TYPE_MODE (TREE_TYPE (arg1)))

•  || TREE_CODE (GENERIC_TREE_TYPE (arg0)) == ERROR_MARK

•  || TREE_CODE (GENERIC_TREE_TYPE (arg1)) == ERROR_MARK

•  || TYPE_MODE (GENERIC_TREE_TYPE (arg0))

•     != TYPE_MODE (GENERIC_TREE_TYPE (arg1)))

  return 0;

  /* If ARG0 and ARG1 are the same SAVE_EXPR, they are necessarily equal.

@@ -2857,8 +2860,8 @@ operand_equal_for_comparison_p (tree arg if (operand_equal_p (arg0, arg1, 0)) return 1;

• if (! INTEGRAL_TYPE_P (TREE_TYPE (arg0))

•  || ! INTEGRAL_TYPE_P (TREE_TYPE (arg1)))

• if (! INTEGRAL_TYPE_P (GENERIC_TREE_TYPE (arg0))

•  || ! INTEGRAL_TYPE_P (GENERIC_TREE_TYPE (arg1)))

  return 0;

  /* Discard any conversions that don't change the modes of ARG0 and ARG1

@@ -2879,12 +2882,12 @@ operand_equal_for_comparison_p (tree arg primarg1 = get_narrower (arg1, &unsignedp1); primother = get_narrower (other, &unsignedpo);

• correct_width = TYPE_PRECISION (TREE_TYPE (arg1));

• correct_width = TYPE_PRECISION (GENERIC_TREE_TYPE (arg1)); if (unsignedp1 == unsignedpo && TYPE_PRECISION (TREE_TYPE (primarg1)) < correct_width && TYPE_PRECISION (TREE_TYPE (primother)) < correct_width) {

•  tree type = TREE_TYPE (arg0);

•  tree type = GENERIC_TREE_TYPE (arg0);
  
   /* Make sure shorter operand is extended the right way
  to match the longer operand.  */

• Follow-Ups:
  • Re: [PATCH] PR30391: GIMPLE_MODIFY_STMT vs. middle-end
    * From: Roger Sayle
• References:
  • [PATCH] PR30391: GIMPLE_MODIFY_STMT vs. middle-end
    * From: Roger Sayle