From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) by sourceware.org (Postfix) with ESMTPS id 8010D3858401 for ; Mon, 31 Oct 2022 21:16:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8010D3858401 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pg1-x52e.google.com with SMTP id q1so11734892pgl.11 for ; Mon, 31 Oct 2022 14:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=NWOuDNUM0dlxWuiRxX+jw8vL24Mi1cc7QkEtGqtM2ic=; b=Jnm52sA3wH/wcJVsH3vsp5BPnIJcOM2Q05CQlIavOyyGGtOXz7/GjvkhDMJE7T/+Ps xQLiOB7c5q/c6ONWmqG0Mi3Kiim0QXD0cjZbmAEYyzwNsZ/e0DPcpnUAOIpAl7rDMT8b lpK8laW8qXW09bax/mVBUDuW8W/9Jib9TJ6xtYjt6vWb1HNA67/I1dyjn3x93LBsEt65 GZlcMVMN6N0fdPo+5roC3ZqEdGK+4hKMMlA63P7syLVBRhk/+/QvkWPbQcDsWhLfdjqM n2VZMS3hKAJBgWqghtXGFOEvQN9LqsXokXZad2AliqjcOaAcq2xXpLwQq2NxVNVr0VdY bF5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=NWOuDNUM0dlxWuiRxX+jw8vL24Mi1cc7QkEtGqtM2ic=; b=CGRNeGO9qS//hOq8wz+8/xpWbpmn43IZ0Il/KbAHOFOxoRd4ccyY30mYCPvZpZ7E8/ s9O8QZ6jJrJHn5u4mCsWJyTb7L0Qb7RKT/kbRktJBP1a7K4x5ywxnD5zG7bVET2V9VC9 Z/GZ5WR8CaT64ty6LdnAiY+jSYDsfz+Qeme2jXnXz+dS0dePxNgvXjIoUQDGyJ9Vk7Ev pm6e1gOu/1P9DhJBaTKDKso1/tMGHGAH8PyPw7KpY+MGUs3QVde/ExmyBOG6NFA5Z4/1 V6TwlTxGZAuGVNKyuzYrKRGB5YdvrnT/IZqRpqwn81hM9564PfO7s6RDEJbtCL6d5gFD RXVQ== X-Gm-Message-State: ACrzQf3nuPgvB/VJjM5/JImIyPXsiAFSsk3LAZJocssrAKTyVhbwowmF FU1DF2BPOTnaEyazaF7eHqg= X-Google-Smtp-Source: AMsMyM6c4QLP+SPGDCiF0AjQfhwYCnxLTqZ/Hd+3hJgBAklcLkC5yc2ynF0SoDwLSFDIMpGfd+0Z9w== X-Received: by 2002:a63:1e47:0:b0:43c:261f:f773 with SMTP id p7-20020a631e47000000b0043c261ff773mr14491311pgm.1.1667250976366; Mon, 31 Oct 2022 14:16:16 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id f13-20020a170902ce8d00b0017f73caf588sm4852724plg.218.2022.10.31.14.16.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 Oct 2022 14:16:15 -0700 (PDT) Message-ID: Date: Mon, 31 Oct 2022 15:16:14 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [PATCH 1/2]middle-end: Add new tbranch optab to add support for bit-test-and-branch operations Content-Language: en-US To: Tamar Christina , gcc-patches@gcc.gnu.org Cc: nd@arm.com, rguenther@suse.de References: From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-8.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 10/31/22 05:53, Tamar Christina wrote: > Hi All, > > This adds a new test-and-branch optab that can be used to do a conditional test > of a bit and branch. This is similar to the cbranch optab but instead can > test any arbitrary bit inside the register. > > This patch recognizes boolean comparisons and single bit mask tests. > > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > > Ok for master? > > Thanks, > Tamar > > gcc/ChangeLog: > > * dojump.cc (do_jump): Pass along value. > (do_jump_by_parts_greater_rtx): Likewise. > (do_jump_by_parts_zero_rtx): Likewise. > (do_jump_by_parts_equality_rtx): Likewise. > (do_compare_rtx_and_jump): Likewise. > (do_compare_and_jump): Likewise. > * dojump.h (do_compare_rtx_and_jump): New. > * optabs.cc (emit_cmp_and_jump_insn_1): Refactor to take optab to check. > (validate_test_and_branch): New. > (emit_cmp_and_jump_insns): Optiobally take a value, and when value is > supplied then check if it's suitable for tbranch. > * optabs.def (tbranch$a4): New. > * doc/md.texi (tbranch@var{mode}4): Document it. > * optabs.h (emit_cmp_and_jump_insns): > * tree.h (tree_zero_one_valued_p): New. > > --- inline copy of patch -- > diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi > index c08691ab4c9a4bfe55ae81e5e228a414d6242d78..f8b32ec12f46d3fb3815f121a16b5a8a1819b66a 100644 > --- a/gcc/doc/md.texi > +++ b/gcc/doc/md.texi > @@ -6972,6 +6972,13 @@ case, you can and should make operand 1's predicate reject some operators > in the @samp{cstore@var{mode}4} pattern, or remove the pattern altogether > from the machine description. > > +@cindex @code{tbranch@var{mode}4} instruction pattern > +@item @samp{tbranch@var{mode}4} > +Conditional branch instruction combined with a bit test-and-compare > +instruction. Operand 0 is a comparison operator. Operand 1 is the > +operand of the comparison. Operand 2 is the bit position of Operand 1 to test. > +Operand 3 is the @code{code_label} to jump to. Should we refine/document the set of comparison operators allowed?    Is operand 1 an arbitrary RTL expression or more limited?  I'm guessing its relatively arbitrary given how you've massaged the existing branch-on-bit patterns from the aarch backend. > + > + if (TREE_CODE (val) != SSA_NAME) > + return false; > + > + gimple *def = SSA_NAME_DEF_STMT (val); > + if (!is_gimple_assign (def) > + || gimple_assign_rhs_code (def) != BIT_AND_EXPR) > + return false; > + > + tree cst = gimple_assign_rhs2 (def); > + > + if (!tree_fits_uhwi_p (cst)) > + return false; > + > + tree op0 = gimple_assign_rhs1 (def); > + if (TREE_CODE (op0) == SSA_NAME) > + { > + def = SSA_NAME_DEF_STMT (op0); > + if (gimple_assign_cast_p (def)) > + op0 = gimple_assign_rhs1 (def); > + } > + > + wide_int wcst = wi::uhwi (tree_to_uhwi (cst), > + TYPE_PRECISION (TREE_TYPE (op0))); > + int bitpos; > + > + if ((bitpos = wi::exact_log2 (wcst)) == -1) > + return false; Do we have enough information lying around from Ranger to avoid the need to walk the def-use chain to discover that we're masking off all but one bit? > > > diff --git a/gcc/tree.h b/gcc/tree.h > index 8f8a9660c9e0605eb516de194640b8c1b531b798..be3d2dee82f692e81082cf21c878c10f9fe9e1f1 100644 > --- a/gcc/tree.h > +++ b/gcc/tree.h > @@ -4690,6 +4690,7 @@ extern tree signed_or_unsigned_type_for (int, tree); > extern tree signed_type_for (tree); > extern tree unsigned_type_for (tree); > extern bool is_truth_type_for (tree, tree); > +extern bool tree_zero_one_valued_p (tree); I don't see a definition of this anywhere. jeff