Re: [PATCH][optabs][ifcvt][1/3] Define negcc, notcc optabs

[Jeff Law <law at redhat dot com>]

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.tkachov@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.tkachov@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