From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) by sourceware.org (Postfix) with ESMTPS id D427B386486E for ; Thu, 27 Oct 2022 03:22:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D427B386486E 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-x533.google.com with SMTP id g129so11055pgc.7 for ; Wed, 26 Oct 2022 20:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=3a4iZvPY9g9nH58OMV2BR83G0w4Y1k5TQuNNb7m5Hl8=; b=AGX3gJ+8/U0DmUeWGyl5Id5Ks8+VVD9jEtFUvMFKHQykuOHwxiGNrQzzu8Vc0t6mm4 q1iqJQY4xf3Z8xac7J02llOfVg8VWSVlCEYPFyv5MY64zV3ZbOBkZSlzdcjvEUbUjMEJ RqWz5uir23B0YguBwaYOUQPqWfk2ZcYTU6SDlQcTB1Lpayr9xEGeTkWDWRoWKdP/Hzi5 hTZ0XEUP0/48P0uRtwjRj4TiW9tnj1ruvRhjwh1onn7NWxLuCEePj9a+XQb8SUT3ZUfp cFXdnxjY7cnuWsaSmwkXuVW6c8Dh7rJnko7Fq1snHv2cYl8vVn86M5Pbm9qMzy5t6rHG pSCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3a4iZvPY9g9nH58OMV2BR83G0w4Y1k5TQuNNb7m5Hl8=; b=EmbX9UNLfjyhqeJXfhyOV8ZS+aGLOJDdTXp/Pb1nAU7RdFbshiGXboSCcdPUzINAO0 /u1UFXfoTMYj/rnh7XwwAwIL8Sh82k1jZ3cdMsPYxFIY8XBCq7ayd31iNTFLV4d7iz4d rzH4KhlKT5Rv4UWaJGY8m59t8hZLiovsVrOrdwZFp87ue6rKVnpiynkvXaWAeD6c4cM1 /OD/QzSTGbTjzfYd0cmTE1F6BQh15Yllvw8nzUbv5rgIj1irCF9PVJut0JIfsXampNGz Pi7sMW1Io5cpYQjmgVZiZFh3eQAyRfAXF+ldi+7YP27dvwLGCMv5pYpNOsAk9EgDNu6L rXSg== X-Gm-Message-State: ACrzQf1TDyyes6HRBkmEecwvQbSJwtyNROB1bEP6OShkI51UKLSvmIAj lHhLOP12Drfr9gP1O+WfFVJjOhkoKaivA1/ldqc= X-Google-Smtp-Source: AMsMyM4qmmK2ZJuVWsX/V6Xa6DRzajQ2/Aj7GuZtfEhw4N8zzFmDD/txaklKopL26GK+YYNyPsG1gPf/zHkN3XASLVM= X-Received: by 2002:a05:6a00:80e:b0:563:4ad2:9d39 with SMTP id m14-20020a056a00080e00b005634ad29d39mr47414202pfk.66.1666840972804; Wed, 26 Oct 2022 20:22:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andrew Pinski Date: Wed, 26 Oct 2022 20:22:40 -0700 Message-ID: Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of conditional branches, give hint if argument is a truth type to backend To: Tamar Christina Cc: gcc-patches@gcc.gnu.org, richard.sandiford@arm.com, nd@arm.com, rguenther@suse.de Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,KAM_SHORT,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 Fri, Sep 23, 2022 at 2:26 AM Tamar Christina via Gcc-patches wrote: > > Hi All, > > This is an RFC to figure out how to deal with targets that don't have native > comparisons against QImode values. > > Booleans, at least in C99 and higher are 0-1 valued. This means that we only > really need to test a single bit. However in RTL we no longer have this > information available and just have an SImode value (due to the promotion of > QImode to SImode). > > This RFC fixes it by emitting an explicit & 1 during the expansion of the > conditional branch. > > However it's unlikely that we want to do this unconditionally. Most targets > I've tested seem to have harmless code changes, like x86 changes from testb to > andl, $1. > > So I have two questions: > > 1. Should I limit this behind a target macro? Or should I just leave it for all > targets and deal with the fallout. > 2. How can I tell whether the C99 0-1 values bools are being used or the older > 0, non-0 variant? > > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > However there are some benign codegen changes on x86, testb changed to andl $1. > > This pattern occurs more than 120,000 times in SPECCPU 2017 and so is quite common. > > Thanks, > Tamar > > gcc/ChangeLog: > > * tree.h (tree_zero_one_valued_p): New. > * dojump.cc (do_jump): Add & 1 if truth type. Just FYI, I think this fixes/improves https://gcc.gnu.org/PR101806 . Thanks, Andrew > > --- inline copy of patch -- > diff --git a/gcc/dojump.cc b/gcc/dojump.cc > index 2af0cd1aca3b6af13d5d8799094ee93f18022296..8eaf1be49cd12298e61c6946ae79ca9de6197864 100644 > --- a/gcc/dojump.cc > +++ b/gcc/dojump.cc > @@ -605,7 +605,17 @@ do_jump (tree exp, rtx_code_label *if_false_label, > /* Fall through and generate the normal code. */ > default: > normal: > - temp = expand_normal (exp); > + tree cmp = exp; > + /* If the expression is a truth type then explicitly generate an & 1 > + to indicate to the target that it's a zero-one values type. This > + allows the target to further optimize the comparison should it > + choose to. */ > + if (tree_zero_one_valued_p (exp)) > + { > + type = TREE_TYPE (exp); > + cmp = build2 (BIT_AND_EXPR, type, exp, build_int_cstu (type, 1)); > + } > + temp = expand_normal (cmp); > do_pending_stack_adjust (); > /* The RTL optimizers prefer comparisons against pseudos. */ > if (GET_CODE (temp) == SUBREG) > 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); > extern tree truth_type_for (tree); > extern tree build_pointer_type_for_mode (tree, machine_mode, bool); > extern tree build_pointer_type (tree); > > > > > --