public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>
To: Richard Sandiford <rdsandiford@googlemail.com>
Cc: gcc-patches@gcc.gnu.org, bernds@codesourcery.com
Subject: Re: Extend widening_mul pass to handle fixed-point types
Date: Thu, 29 Jul 2010 10:39:00 -0000	[thread overview]
Message-ID: <1280399607.10110.33.camel@e102325-lin.cambridge.arm.com> (raw)
In-Reply-To: <87vd7zpdle.fsf@firetop.home>

[-- Attachment #1: Type: text/plain, Size: 6180 bytes --]

Hi Richard,


On Wed, 2010-07-28 at 21:15 +0100, Richard Sandiford wrote:
> Ramana Radhakrishnan <ramana.radhakrishnan@arm.com> writes:
> > Hmmm there are regressions after my patch was applied. I had to do some
> > rebuilds because trunk appears to be broken for other reasons at the
> > minute for ARM which I shall investigate next. 
> 
> Yeah, I think it's the other way about: expand_widen_pattern_expr
> is using the right type and convert_plusminus_to_widen is using
> the wrong one.  The type we pass to optab_for_tree_code determines
> the _sign_ of the multiplication, not the size, so we want to pass
> in the unwidened type.

Thanks for looking at this. Ah - ok. I see what you mean here. 

> 
> > We weren't generating any widening operations before this patch (and I
> > suspect my 2 patches are just for fixing the ICE's and doing the right
> > thing). If it were just adding support for fixed point arithmetic then
> > this is just broken because it shouldn't have changed the way in  which
> > code was generated for normal integer operations.  
> 
> For the record, the patch wasn't just about adding fixed-point support.
> It was also about allowing multiply-accumulate to be used where no plain
> multiplication exists.  So the problem for ARM was that the use of the
> wrong type in convert_plusminus_to_widen was being hidden by the use of
> the right type in convert_mult_widen (i.e. the patch exposed a latent bug).

Thanks for the clarification , that makes more sense now.

> 
> Could you give the attached patch a try?  It also fixes a case where
> the code could create mixed sign-and-unsigned maccs (a bug that existed
> before my patch) and a botched call to is_widening_mult_p (a bug
> introduced by my patch, sorry).

Your patch didn't apply cleanly to pristine trunk or to 162431 and I had
to do a manual merge so I'm not sure if I got all parts of it. 

Just to be absolutely clear, you still need to check for
is_gimple_assign before using the stmt in gimple_assign_lhs in
is_widening_mult_p or do you expect that to get subsumed by your patch ?
Otherwise the compiler ICEs with this testcase [ice-on-gimple-phi.c]. 

Here's what I came up with that includes a manual merge of your patch
assuming I got all the hunks, and my original trivial hunk to
is_widening_mult_p which appeared to fix all the problems with simple
testcases on trunk with a cross-compiler and what I'm bootstrapping and
testing right now.


cheers
Ramana



gcc/
        * tree-ssa-math-opts.c (convert_plusminus_to_widen): Fix type
        used in the call to optab_for_tree_code.  Fix the second
        is_widening_mult_p call.  Check that both unwidened operands
        have the same sign.
	(is_widening_mult_p): Return false if stmt is not a GIMPLE_ASSIGN.



[1]

./xgcc -B`pwd` -S -O2 -mcpu=cortex-a9 ~/ice-on-gimple-phi.c 

assignment./home/ramrad01/ice-on-gimple-phi.c:57:1: internal compiler
error: gimple check: expected gimple_assign(error_mark), have
gimple_phi() in gimple_assign_lhs, at gimple.h:1724

	





> 
> Richard
> 
> 
> gcc/
> 	* tree-ssa-math-opts.c (convert_plusminus_to_widen): Fix type
> 	used in the call to optab_for_tree_code.  Fix the second
> 	is_widening_mult_p call.  Check that both unwidened operands
> 	have the same sign.
> 
> Index: gcc/tree-ssa-math-opts.c
> ===================================================================
> --- gcc/tree-ssa-math-opts.c	2010-07-28 21:09:59.000000000 +0100
> +++ gcc/tree-ssa-math-opts.c	2010-07-28 21:10:00.000000000 +0100
> @@ -1414,13 +1414,6 @@ convert_plusminus_to_widen (gimple_stmt_
>    else
>      wmult_code = WIDEN_MULT_PLUS_EXPR;
>  
> -  /* Verify that the machine can perform a widening multiply
> -     accumulate in this mode/signedness combination, otherwise
> -     this transformation is likely to pessimize code.  */
> -  this_optab = optab_for_tree_code (wmult_code, type, optab_default);
> -  if (optab_handler (this_optab, TYPE_MODE (type)) == CODE_FOR_nothing)
> -    return false;
> -
>    rhs1 = gimple_assign_rhs1 (stmt);
>    rhs2 = gimple_assign_rhs2 (stmt);
>  
> @@ -1447,37 +1440,49 @@ convert_plusminus_to_widen (gimple_stmt_
>        if (!is_widening_mult_p (rhs1_stmt, &type1, &mult_rhs1,
>  			       &type2, &mult_rhs2))
>  	return false;
> -      mult_rhs1 = fold_convert (type1, mult_rhs1);
> -      mult_rhs2 = fold_convert (type2, mult_rhs2);
>        add_rhs = rhs2;
>      }
>    else if (rhs2_code == MULT_EXPR)
>      {
> -      if (!is_widening_mult_p (rhs1_stmt, &type1, &mult_rhs1,
> +      if (!is_widening_mult_p (rhs2_stmt, &type1, &mult_rhs1,
>  			       &type2, &mult_rhs2))
>  	return false;
> -      mult_rhs1 = fold_convert (type1, mult_rhs1);
> -      mult_rhs2 = fold_convert (type2, mult_rhs2);
>        add_rhs = rhs1;
>      }
>    else if (code == PLUS_EXPR && rhs1_code == WIDEN_MULT_EXPR)
>      {
>        mult_rhs1 = gimple_assign_rhs1 (rhs1_stmt);
>        mult_rhs2 = gimple_assign_rhs2 (rhs1_stmt);
> +      type1 = TREE_TYPE (mult_rhs1);
> +      type2 = TREE_TYPE (mult_rhs2);
>        add_rhs = rhs2;
>      }
>    else if (rhs2_code == WIDEN_MULT_EXPR)
>      {
>        mult_rhs1 = gimple_assign_rhs1 (rhs2_stmt);
>        mult_rhs2 = gimple_assign_rhs2 (rhs2_stmt);
> +      type1 = TREE_TYPE (mult_rhs1);
> +      type2 = TREE_TYPE (mult_rhs2);
>        add_rhs = rhs1;
>      }
>    else
>      return false;
>  
> +  if (TYPE_UNSIGNED (type1) != TYPE_UNSIGNED (type2))
> +    return false;
> +
> +  /* Verify that the machine can perform a widening multiply
> +     accumulate in this mode/signedness combination, otherwise
> +     this transformation is likely to pessimize code.  */
> +  this_optab = optab_for_tree_code (wmult_code, type1, optab_default);
> +  if (optab_handler (this_optab, TYPE_MODE (type)) == CODE_FOR_nothing)
> +    return false;
> +
>    /* ??? May need some type verification here?  */
>  
> -  gimple_assign_set_rhs_with_ops_1 (gsi, wmult_code, mult_rhs1, mult_rhs2,
> +  gimple_assign_set_rhs_with_ops_1 (gsi, wmult_code,
> +				    fold_convert (type1, mult_rhs1),
> +				    fold_convert (type2, mult_rhs2),
>  				    add_rhs);
>    update_stmt (gsi_stmt (*gsi));
>    return true;

[-- Attachment #2: pr45067-patch-take4.txt --]
[-- Type: text/x-patch, Size: 3023 bytes --]

Index: tree-ssa-math-opts.c
===================================================================
--- tree-ssa-math-opts.c	(revision 162431)
+++ tree-ssa-math-opts.c	(working copy)
@@ -1323,6 +1323,9 @@ is_widening_mult_p (gimple stmt,
 {
   tree type;
 
+  if (!is_gimple_assign (stmt))
+    return false;
+
   type = TREE_TYPE (gimple_assign_lhs (stmt));
   if (TREE_CODE (type) != INTEGER_TYPE
       && TREE_CODE (type) != FIXED_POINT_TYPE)
@@ -1414,13 +1417,6 @@ convert_plusminus_to_widen (gimple_stmt_
   else
     wmult_code = WIDEN_MULT_PLUS_EXPR;
 
-  /* Verify that the machine can perform a widening multiply
-     accumulate in this mode/signedness combination, otherwise
-     this transformation is likely to pessimize code.  */
-  this_optab = optab_for_tree_code (wmult_code, type, optab_default);
-  if (optab_handler (this_optab, TYPE_MODE (type)) == CODE_FOR_nothing)
-    return false;
-
   rhs1 = gimple_assign_rhs1 (stmt);
   rhs2 = gimple_assign_rhs2 (stmt);
 
@@ -1447,8 +1443,6 @@ convert_plusminus_to_widen (gimple_stmt_
       if (!is_widening_mult_p (rhs1_stmt, &type1, &mult_rhs1,
 			       &type2, &mult_rhs2))
 	return false;
-      mult_rhs1 = fold_convert (type1, mult_rhs1);
-      mult_rhs2 = fold_convert (type2, mult_rhs2);
       add_rhs = rhs2;
     }
   else if (rhs2_code == MULT_EXPR)
@@ -1456,14 +1450,14 @@ convert_plusminus_to_widen (gimple_stmt_
       if (!is_widening_mult_p (rhs1_stmt, &type1, &mult_rhs1,
 			       &type2, &mult_rhs2))
 	return false;
-      mult_rhs1 = fold_convert (type1, mult_rhs1);
-      mult_rhs2 = fold_convert (type2, mult_rhs2);
       add_rhs = rhs1;
     }
   else if (code == PLUS_EXPR && rhs1_code == WIDEN_MULT_EXPR)
     {
       mult_rhs1 = gimple_assign_rhs1 (rhs1_stmt);
       mult_rhs2 = gimple_assign_rhs2 (rhs1_stmt);
+      type1 = TREE_TYPE (mult_rhs1);
+      type2 = TREE_TYPE (mult_rhs2);
       add_rhs = rhs2;
     }
   else if (rhs2_code == WIDEN_MULT_EXPR)
@@ -1471,13 +1465,27 @@ convert_plusminus_to_widen (gimple_stmt_
       mult_rhs1 = gimple_assign_rhs1 (rhs2_stmt);
       mult_rhs2 = gimple_assign_rhs2 (rhs2_stmt);
       add_rhs = rhs1;
+      type1 = TREE_TYPE (mult_rhs1);
+      type2 = TREE_TYPE (mult_rhs2);
     }
   else
     return false;
 
+  if (TYPE_UNSIGNED (type1) != TYPE_UNSIGNED (type2))
+    return false;
+
+  /* Verify that the machine can perform a widening multiply
+     accumulate in this mode/signedness combination, otherwise
+     this transformation is likely to pessimize code.  */
+  this_optab = optab_for_tree_code (wmult_code, type1, optab_default);
+  if (optab_handler (this_optab, TYPE_MODE (type)) == CODE_FOR_nothing)
+    return false;
+
   /* ??? May need some type verification here?  */
 
-  gimple_assign_set_rhs_with_ops_1 (gsi, wmult_code, mult_rhs1, mult_rhs2,
+  gimple_assign_set_rhs_with_ops_1 (gsi, wmult_code,
+				    fold_convert (type1, mult_rhs1),
+				    fold_convert (type2, mult_rhs2),
 				    add_rhs);
   update_stmt (gsi_stmt (*gsi));
   return true;

[-- Attachment #3: ice-on-gimple-phi.c --]
[-- Type: text/x-csrc, Size: 2320 bytes --]

/* ./cc1 -O2 -mcpu=cortex-a9 -quiet reduced.c   */
typedef union tree_node *tree;
enum tree_code {
ERROR_MARK,
};
enum tree_code_class {
  tcc_type,
};
extern const enum tree_code_class tree_code_type[];
struct tree_base {
  __extension__ enum tree_code code : 16;
  unsigned unsigned_flag : 1;
};
struct tree_type {
  unsigned int precision : 10;
};
union
                                                         tree_node {
  struct tree_base base;
  struct tree_type type;
};
enum integer_type_kind
{
  itk_int,
  itk_none
};
extern tree integer_types[itk_none];
typedef struct cpp_reader cpp_reader;
enum c_tree_index
{
    CTI_INTMAX_TYPE,
    CTI_MAX
};
extern tree c_global_trees[CTI_MAX];
static void builtin_define_constants (const char *, tree);
static void
builtin_define_stdint_macros (void)
{
  builtin_define_constants ("__INTMAX_C", c_global_trees[CTI_INTMAX_TYPE]);
}
void
c_cpp_builtins (cpp_reader *pfile)
{
  builtin_define_stdint_macros ();
}
static const char *
type_suffix (tree type)
{
  static const char *const suffixes[] = { "", "U", "L", "UL", "LL", "ULL" };
  int unsigned_suffix;
  int is_long;
  unsigned_suffix = (__extension__ ({ __typeof (type) const __t = (type); if (tree_code_type[(int) (((enum tree_code) (__t)->base.code))] != (tcc_type)) tree_class_check_failed (__t, (tcc_type), "/home/ramrad01/sources/trunk/gcc/c-family/c-cppbuiltin.c", 1084, __FUNCTION__); __t; })->base.unsigned_flag);
  if ((__extension__ ({ __typeof (type) const __t = (type); if (tree_code_type[(int) (((enum tree_code) (__t)->base.code))] != (tcc_type)) tree_class_check_failed (__t, (tcc_type), "/home/ramrad01/sources/trunk/gcc/c-family/c-cppbuiltin.c", 1085, __FUNCTION__); __t; })->type.precision) < (__extension__ ({ __typeof (integer_types[itk_int]) const __t = (integer_types[itk_int]); if (tree_code_type[(int) (((enum tree_code) (__t)->base.code))] != (tcc_type)) tree_class_check_failed (__t, (tcc_type), "/home/ramrad01/sources/trunk/gcc/c-family/c-cppbuiltin.c", 1085, __FUNCTION__); __t; })->type.precision))
  return suffixes[is_long * 2 + unsigned_suffix];
}
static void
builtin_define_constants (const char *macro, tree type)
{
  const char *suffix;
  char *buf;
  suffix = type_suffix (type);
  if (suffix[0] == 0)
    {
      buf = (char *) __builtin_alloca(strlen (macro) + 6);
    }
}

  reply	other threads:[~2010-07-29 10:33 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-18 12:03 Richard Sandiford
2010-07-18 20:47 ` Bernd Schmidt
2010-07-19 18:35   ` Richard Sandiford
2010-07-19 21:53     ` Bernd Schmidt
2010-07-27 12:28       ` Ramana Radhakrishnan
2010-07-27 15:54         ` Bernd Schmidt
2010-07-27 17:10           ` Ramana Radhakrishnan
2010-07-28 15:43           ` Ramana Radhakrishnan
2010-07-28 21:20             ` Richard Sandiford
2010-07-29 10:39               ` Ramana Radhakrishnan [this message]
2010-07-31  9:45                 ` Richard Sandiford
2010-07-31  9:45               ` Richard Sandiford
2010-07-31 13:03                 ` Bernd Schmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1280399607.10110.33.camel@e102325-lin.cambridge.arm.com \
    --to=ramana.radhakrishnan@arm.com \
    --cc=bernds@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=rdsandiford@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).