On 09/01/2015 09:04 AM, Kyrill Tkachov wrote:
Hi all,
This first patch introduces the negcc and notcc optabs that should
expand to a conditional
negate or a conditional bitwise complement operation.
These are used in ifcvt.c to transform code of the form:
if (test) x = -A; else x = A;
into:
x = A; if (test) x = -x;
where the "if (test) x = -x;" is implemented using the negcc (or notcc
in the ~x case)
if such an optab is available. If such an optab is not implemented then
no transformation
is performed. Thus, without patches 2/3 and 3/3 this patch does not
impact behaviour on any target.
Bootstrapped and tested as part of the series on arm, aarch64, x86_64.
Ok for trunk?
Thanks,
Kyrill
2015-09-01 Kyrylo Tkachov <kyrylo.tkac...@arm.com>
* ifcvt.c (noce_try_inverse_constants): New function.
(noce_process_if_block): Call it.
* optabs.h (emit_conditional_neg_or_complement): Declare prototype.
* optabs.def (negcc_optab, notcc_optab): Declare.
* optabs.c (emit_conditional_neg_or_complement): New function.
* doc/tm.texi (Standard Names): Document negcc, notcc names.
negnotcc-optabs.patch
commit a2183218070ed5f2dca0a9651fdb08ce134ba8ee
Author: Kyrylo Tkachov<kyrylo.tkac...@arm.com>
Date: Thu Aug 13 18:14:52 2015 +0100
[optabs][ifcvt][1/3] Define negcc, notcc optabs
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index 0bffdc6..5038269 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -5791,6 +5791,21 @@ move operand 2 or (operands 2 + operand 3) into operand
0 according to the
comparison in operand 1. If the comparison is false, operand 2 is moved into
operand 0, otherwise (operand 2 + operand 3) is moved.
+@cindex @code{neg@var{mode}cc} instruction pattern
+@item @samp{neg@var{mode}cc}
+Similar to @samp{mov@var{mode}cc} but for conditional negation. Conditionally
+move the negation of operand 2 operand 3 into operand 0 according to the
+comparison in operand 1. If the comparison is true, the negation of operand 2
+is moved into operand 0, otherwise operand 3 is moved.
+
+@cindex @code{not@var{mode}cc} instruction pattern
+@item @samp{not@var{mode}cc}
+Similar to @samp{neg@var{mode}cc} but for conditional complement.
+Conditionally move the bitwise complement of operand 2 operand 3 into operand 0
+according to the comparison in operand 1. If the comparison is true,
+the complement of operand 2 is moved into operand 0, otherwise operand 3 is
+moved.
"operand 2 operand 3" does not parse. I think you mean "operand 2 or
operand 3" in both instances above. Even that doesn't parse well as
it's not clear if operand3 or the negation/complement of operand 3 is
meant. Can you try to improve the ambiguity of the second sentence in
each description.
And just a note. The canonical way to refer to these patterns should be
negcc/notcc. That avoids conflicting with the older negscc patterns
with different semantics that are defined by some ports. You're already
using that terminology, so there's nothing to change, I just wanted to
point it out.
+
+ rtx_code code;
+ if (val_a == -val_b)
Do we have to worry about signed overflow here? I'm thinking
specifically when val_b is the smallest possible integer representable
by a HOST_WIDE_INT. I suspect you may be able to avoid these problems
with judicious use of the hwi interfaces.
So I think we just need to resolve the doc change and make sure we're
not triggering undefined behaviour above and this can go forward.
jeff