From: Richard Sandiford <rdsandiford@googlemail.com>
To: ramana.radhakrishnan@arm.com
Cc: Bernd Schmidt <bernds@codesourcery.com>, gcc-patches@gcc.gnu.org
Subject: Re: Extend widening_mul pass to handle fixed-point types
Date: Wed, 28 Jul 2010 21:20:00 -0000 [thread overview]
Message-ID: <87vd7zpdle.fsf@firetop.home> (raw)
In-Reply-To: <1280331613.18689.137.camel@e102325-lin.cambridge.arm.com> (Ramana Radhakrishnan's message of "Wed, 28 Jul 2010 16:40:13 +0100")
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.
> 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).
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).
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;
next prev parent reply other threads:[~2010-07-28 20:15 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 [this message]
2010-07-29 10:39 ` Ramana Radhakrishnan
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=87vd7zpdle.fsf@firetop.home \
--to=rdsandiford@googlemail.com \
--cc=bernds@codesourcery.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=ramana.radhakrishnan@arm.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).