public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: Andrew Carlotti <andrew.carlotti@arm.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH 5/8] middle-end: Add cltz_complement idiom recognition
Date: Thu, 24 Nov 2022 11:41:31 +0100	[thread overview]
Message-ID: <CAFiYyc1PQj5KetQYyP4W+fhdBsoBgrJBoeZai0T022CcS-P2mA@mail.gmail.com> (raw)
In-Reply-To: <Y3ue4N1QBrIs4a+x@e124511.cambridge.arm.com>

On Mon, Nov 21, 2022 at 4:53 PM Andrew Carlotti <andrew.carlotti@arm.com> wrote:
>
> On Mon, Nov 14, 2022 at 04:10:22PM +0100, Richard Biener wrote:
> > On Fri, Nov 11, 2022 at 7:53 PM Andrew Carlotti via Gcc-patches
> > <gcc-patches@gcc.gnu.org> wrote:
> > >
> > > This recognises patterns of the form:
> > > while (n) { n >>= 1 }
> > >
> > > This patch results in improved (but still suboptimal) codegen:
> > >
> > > foo (unsigned int b) {
> > >     int c = 0;
> > >
> > >     while (b) {
> > >         b >>= 1;
> > >         c++;
> > >     }
> > >
> > >     return c;
> > > }
> > >
> > > foo:
> > > .LFB11:
> > >         .cfi_startproc
> > >         cbz     w0, .L3
> > >         clz     w1, w0
> > >         tst     x0, 1
> > >         mov     w0, 32
> > >         sub     w0, w0, w1
> > >         csel    w0, w0, wzr, ne
> > >         ret
> > >
> > > The conditional is unnecessary. phiopt could recognise a redundant csel
> > > (using cond_removal_in_builtin_zero_pattern) when one of the inputs is a
> > > clz call, but it cannot recognise the redunancy when the input is (e.g.)
> > > (32 - clz).
> > >
> > > I could perhaps extend this function to recognise this pattern in a later
> > > patch, if this is a good place to recognise more patterns.
> > >
> > > gcc/ChangeLog:
> > >
> +           PR tree-optimization/94793
> > >         * tree-scalar-evolution.cc (expression_expensive_p): Add checks
> > >         for c[lt]z optabs.
> > >         * tree-ssa-loop-niter.cc (build_cltz_expr): New.
> > >         (number_of_iterations_cltz_complement): New.
> > >         (number_of_iterations_bitcount): Add call to the above.
> > >
> > > gcc/testsuite/ChangeLog:
> > >
> > >         * lib/target-supports.exp (check_effective_target_clz)
> > >         (check_effective_target_clzl, check_effective_target_clzll)
> > >         (check_effective_target_ctz, check_effective_target_clzl)
> > >         (check_effective_target_ctzll): New.
> > >         * gcc.dg/tree-ssa/cltz-complement-max.c: New test.
> > >         * gcc.dg/tree-ssa/clz-complement-char.c: New test.
> > >         * gcc.dg/tree-ssa/clz-complement-int.c: New test.
> > >         * gcc.dg/tree-ssa/clz-complement-long-long.c: New test.
> > >         * gcc.dg/tree-ssa/clz-complement-long.c: New test.
> > >         * gcc.dg/tree-ssa/ctz-complement-char.c: New test.
> > >         * gcc.dg/tree-ssa/ctz-complement-int.c: New test.
> > >         * gcc.dg/tree-ssa/ctz-complement-long-long.c: New test.
> > >         * gcc.dg/tree-ssa/ctz-complement-long.c: New test.
> > >
> > >
> > > --
> > >
> > >
>
> [snip test diffs]
>
> > > diff --git a/gcc/tree-scalar-evolution.cc b/gcc/tree-scalar-evolution.cc
> > > index 7e2a3e986619de87e4ae9daf16198be1f13b917c..1ac9526c69b5fe80c26022f2fa1176d222e2dfb9 100644
> > > --- a/gcc/tree-scalar-evolution.cc
> > > +++ b/gcc/tree-scalar-evolution.cc
> > > @@ -3406,12 +3406,21 @@ expression_expensive_p (tree expr, hash_map<tree, uint64_t> &cache,
> > >          library call for popcount when backend does not have an instruction
> > >          to do so.  We consider this to be expensive and generate
> > >          __builtin_popcount only when backend defines it.  */
> > > +      optab optab;
> > >        combined_fn cfn = get_call_combined_fn (expr);
> > >        switch (cfn)
> > >         {
> > >         CASE_CFN_POPCOUNT:
> > > +         optab = popcount_optab;
> > > +         goto bitcount_call;
> > > +       CASE_CFN_CLZ:
> > > +         optab = clz_optab;
> > > +         goto bitcount_call;
> > > +       CASE_CFN_CTZ:
> > > +         optab = ctz_optab;
> > > +bitcount_call:
> > >           /* Check if opcode for popcount is available in the mode required.  */
> > > -         if (optab_handler (popcount_optab,
> > > +         if (optab_handler (optab,
> > >                              TYPE_MODE (TREE_TYPE (CALL_EXPR_ARG (expr, 0))))
> > >               == CODE_FOR_nothing)
> > >             {
> > > @@ -3424,7 +3433,7 @@ expression_expensive_p (tree expr, hash_map<tree, uint64_t> &cache,
> > >                  instructions.  */
> > >               if (is_a <scalar_int_mode> (mode, &int_mode)
> > >                   && GET_MODE_SIZE (int_mode) == 2 * UNITS_PER_WORD
> > > -                 && (optab_handler (popcount_optab, word_mode)
> > > +                 && (optab_handler (optab, word_mode)
> > >                       != CODE_FOR_nothing))
> > >                   break;
> > >               return true;
> > > diff --git a/gcc/tree-ssa-loop-niter.cc b/gcc/tree-ssa-loop-niter.cc
> > > index fece876099c1687569d6351e7d2416ea6acae5b5..16e8e25919d808cea27adbd72f0be01ae2f0e547 100644
> > > --- a/gcc/tree-ssa-loop-niter.cc
> > > +++ b/gcc/tree-ssa-loop-niter.cc
> > > @@ -2198,6 +2198,195 @@ number_of_iterations_popcount (loop_p loop, edge exit,
> > >    return true;
> > >  }
> > >
> > > +/* Return an expression that counts the leading/trailing zeroes of src.  */
> >
> > Can you expand the comment on how you handle defined_at_zero and how
> > that relates to the C[LT]Z_DEFINED_VALUE_AT_ZERO target macros?
> > The loop examples you gave above all have a defined value for zero, I'm
> > not sure how you'd write a C loop which has that undefined.
> >
>
> How about:
>
> /* Return an expression that counts the leading/trailing zeroes of src.
>
>    If defined_at_zero is true, then the built expression uses a conditonal
>    expression to return the precision of src when src == 0.
>    Otherwise, we can elide the conditional expression and let src = 0 invoke
>    undefined behaviour.  */

Ah, yes - that makes things clearer.

>
> > > +static tree
> > > +build_cltz_expr (tree src, bool leading, bool defined_at_zero)
> > > +{
> > > +  tree fn;
> > > +  int prec = TYPE_PRECISION (TREE_TYPE (src));
> > > +  int i_prec = TYPE_PRECISION (integer_type_node);
> > > +  int li_prec = TYPE_PRECISION (long_integer_type_node);
> > > +  int lli_prec = TYPE_PRECISION (long_long_integer_type_node);
> > > +  if (prec <= i_prec)
> >
> > I don't think we can use <= for both CLZ and CTZ, no?  You probably
> > need a GIMPLE testcase or a language that doesn't promote char/short
> > to int for a testcase that fails though.
>
> I don't see an issue here.  I've ensured that src is the mode used in
> the iterator, and if a longer mode is used for the __builtin_clz
> call then I account for the difference below...
>
> > > +    fn = leading ? builtin_decl_implicit (BUILT_IN_CLZ)
> > > +                : builtin_decl_implicit (BUILT_IN_CTZ);
> > > +  else if (prec == li_prec)
> > > +    fn = leading ? builtin_decl_implicit (BUILT_IN_CLZL)
> > > +                : builtin_decl_implicit (BUILT_IN_CTZL);
> > > +  else if (prec == lli_prec || prec == 2 * lli_prec)
> > > +    fn = leading ? builtin_decl_implicit (BUILT_IN_CLZLL)
> > > +                : builtin_decl_implicit (BUILT_IN_CTZLL);
> > > +  else
> > > +    return NULL_TREE;
> > > +
> > > +  tree utype = unsigned_type_for (TREE_TYPE (src));
> > > +  src = fold_convert (utype, src);
> > > +  if (prec < i_prec)
> > > +    src = fold_convert (unsigned_type_node, src);
> > > +

but if you have an unsigned short variable you promote
that to unsigned int here, no?

> > > +  tree call;
> > > +  if (prec == 2 * lli_prec)
> > > +    {
> > > +      tree src1 = fold_convert (long_long_unsigned_type_node,
> > > +                               fold_build2 (RSHIFT_EXPR, TREE_TYPE (src),
> > > +                                            unshare_expr (src),
> > > +                                            build_int_cst (integer_type_node,
> > > +                                                           lli_prec)));
> > > +      tree src2 = fold_convert (long_long_unsigned_type_node, src);
> > > +      /* We count the zeroes in src1, and add the number in src2 when src1
> > > +        is 0.  */
> > > +      if (!leading)
> > > +       std::swap(src1, src2);
> > > +      tree call1 = build_call_expr (fn, 1, src1);
> > > +      tree call2 = build_call_expr (fn, 1, src2);
> > > +      if (defined_at_zero)
> > > +       {
> > > +         tree is_zero2 = fold_build2 (NE_EXPR, boolean_type_node, src2,
> > > +                                      build_zero_cst (TREE_TYPE (src2)));
> > > +         call2 = fold_build3(COND_EXPR, integer_type_node, is_zero2, call2,
> > > +                             build_int_cst (integer_type_node, lli_prec));
> > > +       }
> > > +      tree is_zero1 = fold_build2 (NE_EXPR, boolean_type_node, src1,
> > > +                                  build_zero_cst (TREE_TYPE (src1)));
> > > +      call = fold_build3(COND_EXPR, integer_type_node, is_zero1, call1,
> > > +                        fold_build2 (PLUS_EXPR, integer_type_node, call2,
> > > +                                     build_int_cst (integer_type_node,
> > > +                                                    lli_prec)));
> > > +    }
> > > +  else
> > > +    {
> > > +      call = build_call_expr (fn, 1, src);
> > > +      if (defined_at_zero)
> > > +       {
> > > +         tree is_zero = fold_build2 (NE_EXPR, boolean_type_node, src,
> > > +                                     build_zero_cst (TREE_TYPE (src)));
> > > +         call = fold_build3(COND_EXPR, integer_type_node, is_zero, call,
> > > +                            build_int_cst (integer_type_node, prec));
> > > +       }
> > > +    }
> > > +
>
> ...with this code:
>
> > > +  if (leading && prec < i_prec)
> > > +    call = fold_build2(MINUS_EXPR, integer_type_node, call,
> > > +                      build_int_cst (integer_type_node,
> > > +                                     i_prec - prec));

... ah, OK.  Indeed, that should work.  Note we do have CTZ and CLZ
optabs and internal functions - in case there's a HImode CLZ this
could be elided.  More general you can avoid using the __builtin_
functions with their fixed types in favor of using IFN_C[TL]Z which
are type agnostic (but require optab support - you should be able
to check this via direct_internal_fn_supported_p).

> > > +  return call;
> > > +}
> > > +
> > > +/* See comment below for number_of_iterations_bitcount.
> > > +   For c[lt]z complement, we have:
> > > +
> > > +   modify:
> > > +   iv_2 = iv_1 >> 1 OR iv_1 << 1
> > > +
> > > +   test:
> > > +   if (iv != 0)
> > > +
> > > +   modification count:
> > > +   src precision - c[lt]z (src)
> > > +
> > > + */
> > > +
> > > +static bool
> > > +number_of_iterations_cltz_complement (loop_p loop, edge exit,
> > > +                              enum tree_code code,
> > > +                              class tree_niter_desc *niter)
> > > +{
> > > +  bool modify_before_test = true;
> > > +  HOST_WIDE_INT max;
> > > +
> > > +  /* Check that condition for staying inside the loop is like
> > > +     if (iv != 0).  */
> > > +  gimple *cond_stmt = last_stmt (exit->src);
> > > +  if (!cond_stmt
> > > +      || gimple_code (cond_stmt) != GIMPLE_COND
> > > +      || code != NE_EXPR
> > > +      || !integer_zerop (gimple_cond_rhs (cond_stmt))
> > > +      || TREE_CODE (gimple_cond_lhs (cond_stmt)) != SSA_NAME)
> > > +    return false;
> > > +
> > > +  tree iv_2 = gimple_cond_lhs (cond_stmt);
> > > +  gimple *iv_2_stmt = SSA_NAME_DEF_STMT (iv_2);
> > > +
> > > +  /* If the test comes before the iv modification, then these will actually be
> > > +     iv_1 and a phi node.  */
> > > +  if (gimple_code (iv_2_stmt) == GIMPLE_PHI
> > > +      && gimple_bb (iv_2_stmt) == loop->header
> > > +      && gimple_phi_num_args (iv_2_stmt) == 2
> > > +      && (TREE_CODE (gimple_phi_arg_def (iv_2_stmt,
> > > +                                        loop_latch_edge (loop)->dest_idx))
> > > +         == SSA_NAME))
> > > +    {
> > > +      /* iv_2 is actually one of the inputs to the phi.  */
> > > +      iv_2 = gimple_phi_arg_def (iv_2_stmt, loop_latch_edge (loop)->dest_idx);
> > > +      iv_2_stmt = SSA_NAME_DEF_STMT (iv_2);
> > > +      modify_before_test = false;
> > > +    }
> > > +
> > > +  /* Make sure iv_2_stmt is a logical shift by one stmt:
> > > +     iv_2 = iv_1 {>>|<<} 1  */
> > > +  if (!is_gimple_assign (iv_2_stmt)
> > > +      || (gimple_assign_rhs_code (iv_2_stmt) != LSHIFT_EXPR
> > > +         && (gimple_assign_rhs_code (iv_2_stmt) != RSHIFT_EXPR
> > > +             || !TYPE_UNSIGNED (TREE_TYPE (gimple_assign_lhs (iv_2_stmt)))))
> > > +      || !integer_onep (gimple_assign_rhs2 (iv_2_stmt)))
> > > +    return false;
> > > +
> > > +  bool left_shift = (gimple_assign_rhs_code (iv_2_stmt) == LSHIFT_EXPR);
> > > +
> > > +  tree iv_1 = gimple_assign_rhs1 (iv_2_stmt);
> > > +
> > > +  /* Check the recurrence.  */
> > > +  gimple *phi = SSA_NAME_DEF_STMT (iv_1);
> > > +  if (gimple_code (phi) != GIMPLE_PHI
> > > +      || (gimple_bb (phi) != loop_latch_edge (loop)->dest)
> > > +      || (iv_2 != gimple_phi_arg_def (phi, loop_latch_edge (loop)->dest_idx)))
> > > +    return false;
> > > +
> > > +  /* We found a match.  */
> > > +  tree src = gimple_phi_arg_def (phi, loop_preheader_edge (loop)->dest_idx);
> > > +  int src_precision = TYPE_PRECISION (TREE_TYPE (src));
> > > +
> > > +  /* Get the corresponding c[lt]z builtin.  */
> > > +  tree expr = build_cltz_expr (src, !left_shift, true);
> >
> > So we always have defined_at_zero == true?
>
> In the patch: yes.  The next patch uses defined_at_zero == false, and I
> don't think there's any point in submitting a simpler build_cltz_expr
> for just this patch.
>
> > > +
> > > +  if (!expr)
> > > +    return false;
> > > +
> > > +  expr = fold_build2 (MINUS_EXPR, integer_type_node,
> > > +                     build_int_cst (integer_type_node, src_precision),
> > > +                     expr);
> > > +
> > > +  max = src_precision;
> > > +
> > > +  tree may_be_zero = boolean_false_node;
> > > +
> > > +  if (modify_before_test)
> > > +    {
> > > +      expr = fold_build2 (MINUS_EXPR, integer_type_node, expr,
> > > +                         integer_one_node);
> > > +      max = max - 1;
> > > +      may_be_zero = fold_build2 (EQ_EXPR, boolean_type_node, src,
> > > +                                     build_zero_cst (TREE_TYPE (src)));
> > > +    }
> > > +
> > > +  expr = fold_convert (unsigned_type_node, expr);
> > > +
> > > +  niter->assumptions = boolean_true_node;
> > > +  niter->may_be_zero = simplify_using_initial_conditions (loop, may_be_zero);
> > > +  niter->niter = simplify_using_initial_conditions (loop, expr);
> > > +
> > > +  if (TREE_CODE (niter->niter) == INTEGER_CST)
> > > +    niter->max = tree_to_uhwi (niter->niter);
> > > +  else
> > > +    niter->max = max;
> > > +
> > > +  niter->bound = NULL_TREE;
> > > +  niter->cmp = ERROR_MARK;
> > > +  return true;
> > > +}
> > > +
> > >  /* See if LOOP contains a bit counting idiom. The idiom consists of two parts:
> > >     1. A modification to the induction variabler;.
> > >     2. A test to determine whether or not to exit the loop.
> > > @@ -2244,7 +2433,8 @@ number_of_iterations_bitcount (loop_p loop, edge exit,
> > >                                enum tree_code code,
> > >                                class tree_niter_desc *niter)
> > >  {
> > > -  return number_of_iterations_popcount (loop, exit, code, niter);
> > > +  return (number_of_iterations_popcount (loop, exit, code, niter)
> > > +         || number_of_iterations_cltz_complement (loop, exit, code, niter));
> >
> > I'm kind-of missing the non-complement variant ;)
>
> See next patch :)
>
> > Otherwise looks OK to me.
> >
> > Thanks,
> > Richard.
> >
> > >  }
> > >
> > >  /* Substitute NEW_TREE for OLD in EXPR and fold the result.

  reply	other threads:[~2022-11-24 10:41 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-11 13:29 [PATCH 0/8] middle-end: Popcount and clz/ctz idiom recognition improvements Andrew Carlotti
2022-11-11 13:39 ` [PATCH 0/8] middle-end: Ensure at_stmt is defined before an early exit Andrew Carlotti
2022-11-14 14:23   ` Jeff Law
2022-11-11 13:46 ` [PATCH 2/8] middle-end: Remove prototype for number_of_iterations_popcount Andrew Carlotti
2022-11-14 14:24   ` Jeff Law
2022-11-11 13:52 ` [PATCH 3/8] middle-end: Refactor number_of_iterations_popcount Andrew Carlotti
2022-11-14 14:52   ` Richard Biener
2022-11-11 18:43 ` [PATCH 4/8] Modify test, to prevent the next patch breaking it Andrew Carlotti
2022-11-14 10:18   ` Richard Biener
2022-11-11 18:50 ` [PATCH 5/8] middle-end: Add cltz_complement idiom recognition Andrew Carlotti
2022-11-14 15:10   ` Richard Biener
2022-11-21 15:53     ` Andrew Carlotti
2022-11-24 10:41       ` Richard Biener [this message]
2022-12-22 17:42         ` [PATCH 5/8 v2] " Andrew Carlotti
2023-01-12 13:19           ` Richard Biener
2023-01-19  9:19           ` Jan-Benedict Glaw
2023-01-19  9:43             ` Richard Biener
2022-11-11 18:54 ` [PATCH 6/8] docs: Add popcount, clz and ctz target attributes Andrew Carlotti
2022-11-14 14:52   ` Jeff Law
2022-12-22 17:42     ` [PATCH 6/8 v2] " Andrew Carlotti
2022-11-11 19:01 ` [PATCH 7/8] middle-end: Add c[lt]z idiom recognition Andrew Carlotti
2022-11-14 15:22   ` Richard Biener
2022-11-11 19:07 ` [PATCH 8/8] middle-end: Expand comment for tree_niter_desc.max Andrew Carlotti
2022-11-14 14:51   ` Jeff Law
2022-12-22 17:43 ` [PATCH 9/8] middle-end: Allow build_popcount_expr to use an IFN Andrew Carlotti
2023-01-12 13:20   ` Richard Biener
2023-01-16 14:03   ` Andrew Carlotti
2023-01-16 14:07     ` Andrew Carlotti

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=CAFiYyc1PQj5KetQYyP4W+fhdBsoBgrJBoeZai0T022CcS-P2mA@mail.gmail.com \
    --to=richard.guenther@gmail.com \
    --cc=andrew.carlotti@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    /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).