Message ID | 019801dadd1d$936d12c0$ba473840$@nextmovesoftware.com |
---|---|
State | New |
Headers | show |
Series | [match.pd] Fold ctz(-x) as ctz(x). | expand |
On Tue, Jul 23, 2024 at 9:30 AM Roger Sayle <roger@nextmovesoftware.com> wrote: > > > The subject line pretty much says it all; the count-trailing-zeros function > of -X produces the same result as count-trailing-zeros of X. This > transformation eliminates a negation which may potentially overflow with > an equivalent expression that doesn't [much like the analogous abs(-X) > simplification in match.pd]. Likewise, the undefined at zero remains > undefined. > > I'd noticed this equivalence, which isn't mentioned in Hacker's Delight, > investigating whether ranger's non_zero_bits can help determine whether > an integer variable may be converted to a floating point type exactly > (without raising FE_INEXACT), but it turns out this observation isn't > novel, as (disappointingly) LLVM already performs this same folding. > > This patch has been tested on x86_64-pc-linux-gnu with make bootstrap > and make -k check, both with and without --target_board=unix{-m32} > with no new failures. Ok for mainline? > > 2024-07-23 Roger Sayle <roger@nextmovesoftware.com> > > gcc/ChangeLog > * match.pd (ctz (-X) => ctz (X)): New simplification. ``` int f1(int a) { return __builtin_ctz(__builtin_abs(a)); } ``` Should also be handled. Though this might be good to handle in the backprop pass (gimple-ssa-backprop.cc) which handles sign changes like this already. Thanks, Andrew Pinski > > gcc/testsuite/ChangeLog > * gcc.dg/fold-ctz-1.c: New test case. > > > Thanks in advance, > Roger > -- >
On 7/23/24 10:30 AM, Roger Sayle wrote: > > The subject line pretty much says it all; the count-trailing-zeros function > of -X produces the same result as count-trailing-zeros of X. This > transformation eliminates a negation which may potentially overflow with > an equivalent expression that doesn't [much like the analogous abs(-X) > simplification in match.pd]. Likewise, the undefined at zero remains > undefined. > > I'd noticed this equivalence, which isn't mentioned in Hacker's Delight, > investigating whether ranger's non_zero_bits can help determine whether > an integer variable may be converted to a floating point type exactly > (without raising FE_INEXACT), but it turns out this observation isn't > novel, as (disappointingly) LLVM already performs this same folding. > > This patch has been tested on x86_64-pc-linux-gnu with make bootstrap > and make -k check, both with and without --target_board=unix{-m32} > with no new failures. Ok for mainline? > > 2024-07-23 Roger Sayle <roger@nextmovesoftware.com> > > gcc/ChangeLog > * match.pd (ctz (-X) => ctz (X)): New simplification. > > gcc/testsuite/ChangeLog > * gcc.dg/fold-ctz-1.c: New test case. OK. Your call on how to handle the additional case that Andrew P. noted. jeff
diff --git a/gcc/match.pd b/gcc/match.pd index 6818856..d6d61eb 100644 --- a/gcc/match.pd +++ b/gcc/match.pd @@ -9056,6 +9056,11 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) /* CTZ simplifications. */ (for ctz (CTZ) + /* ctz (-x) => ctz (x). */ + (simplify + (ctz (nop_convert?@0 (negate @1))) + (with { tree t = TREE_TYPE (@0); } + (ctz (convert:t @1)))) (for op (ge gt le lt) cmp (eq eq ne ne) (simplify diff --git a/gcc/testsuite/gcc.dg/fold-ctz-1.c b/gcc/testsuite/gcc.dg/fold-ctz-1.c new file mode 100644 index 0000000..dcc444c --- /dev/null +++ b/gcc/testsuite/gcc.dg/fold-ctz-1.c @@ -0,0 +1,9 @@ +/* { dg-do compile } */ +/* { dg-options "-O2 -fdump-tree-optimized" } */ + +int foo(int x) +{ + return __builtin_ctz (-x); +} + +/* { dg-final { scan-tree-dump-not "-x_" "optimized"} } */