From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by sourceware.org (Postfix) with ESMTPS id F39F23858D35 for ; Thu, 16 Mar 2023 14:48:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F39F23858D35 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-pj1-x1029.google.com with SMTP id nn12so1858549pjb.5 for ; Thu, 16 Mar 2023 07:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678978095; 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=BDK78FAqCdSVvMj+2w+e/55dYc37b+o9J0D1Fx51AEs=; b=f40NcXbgtsJQhkR7YMsAnew9eKx0Op82yhbb2ZX0GiqP4xcRbp9y8J1rWnwJDXJ4QU JfxQ7NuLJTsoM5U5UPK0UMhB1TVmoX4fopMgbNTqO8H4MqFJK634D4mtQk/e+iPAKXE4 ainDrslYpWVXauc7XBo2EyokMhog+vD17RSwC5HD4Oyf1DujQqLgKjLsngU6WHkkrE7m sBdOHWYvmAsrm2qCvgQwIBEUCzOv4subeYTAdJ1b3cAxqQdozGiYehLHRVGPaUHV86TA Ndy3XICgQ9+y1sKEa3ccvnFFlq9qkFIVcCRGp5vq5aarZe0I6M8o+cSn6k0Ulopdd+Ru xbvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678978095; 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=BDK78FAqCdSVvMj+2w+e/55dYc37b+o9J0D1Fx51AEs=; b=K/2IFY5aJfGB0XmrXfJb5D9YD6Z27P56ZI5jFR4y+hRcvhK/vYNXy+BrwSIHdGDWOY 7B/JIKXFsA7rkRQuZirtQCJ+8JXS13SIAEhQsmYgJ0OKCHwNo5iz5aCw6UeVmtlR+5Gz n9UPkNzCmnWvb6FyI4uHJhNCtcAMJt62tE4NS5FvhTZaVe/tm9QXfPrlCsGRoWsRhOqx eExHgQ16y4i9oN80LE2URLNf0KSleBnn5bqkcj/isYVYESV6uqMhbOJpibCdFZ+JjWH7 l9lC+z6aEwsZsN1KXr7U0gL7hfULXQSLzMbmbyJ0l+BrMYArDjx4OwQNp19xitanedgC d3gw== X-Gm-Message-State: AO0yUKVpTaZvkRDzENv0aPmdwgxlgMTSI0+auHecdn3foo8owkhzy7s3 e2JSapx8N9RHxNC/rYyNyec= X-Google-Smtp-Source: AK7set8wftfOVfrTujndZBVEgQJJxCPIInAQAGF2oY+67PPJwQPTeXlYrWU0Cdqu++tyEHkSdkSwCw== X-Received: by 2002:a17:903:283:b0:1a0:4341:4cd9 with SMTP id j3-20020a170903028300b001a043414cd9mr4498915plr.31.1678978094731; Thu, 16 Mar 2023 07:48:14 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id kf11-20020a17090305cb00b0019f2a7f4d16sm5713709plb.39.2023.03.16.07.48.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Mar 2023 07:48:14 -0700 (PDT) Message-ID: <162d0f3f-0515-9e26-cbf7-7564537f8783@gmail.com> Date: Thu, 16 Mar 2023 08:48:13 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH] rs6000: suboptimal code for returning bool value on target ppc Content-Language: en-US To: Ajit Agarwal , Richard Biener Cc: gcc-patches , Segher Boessenkool , bergner@linux.ibm.com References: <86cf8475-4353-52ca-869c-75f40bd7d06f@linux.ibm.com> <55b2d830-e71b-8b8a-948d-103b75aea1df@linux.ibm.com> <46a7e308-773d-fc27-5905-41ce3d531653@linux.ibm.com> <68ae93ab-ecb9-332b-dba8-bdc7b0d6b3c9@linux.ibm.com> From: Jeff Law In-Reply-To: <68ae93ab-ecb9-332b-dba8-bdc7b0d6b3c9@linux.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,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 3/16/23 04:11, Ajit Agarwal via Gcc-patches wrote: > > Hello Richard: > > On 16/03/23 3:22 pm, Richard Biener wrote: >> On Thu, Mar 16, 2023 at 9:19 AM Ajit Agarwal wrote: >>> >>> >>> >>> On 16/03/23 1:44 pm, Richard Biener wrote: >>>> On Thu, Mar 16, 2023 at 9:11 AM Ajit Agarwal wrote: >>>>> >>>>> Hello Richard: >>>>> >>>>> On 16/03/23 1:10 pm, Richard Biener wrote: >>>>>> On Thu, Mar 16, 2023 at 6:21 AM Ajit Agarwal via Gcc-patches >>>>>> wrote: >>>>>>> >>>>>>> Hello All: >>>>>>> >>>>>>> >>>>>>> This patch eliminates unnecessary zero extension instruction from power generated assembly. >>>>>>> Bootstrapped and regtested on powerpc64-linux-gnu. >>>>>> >>>>>> What makes this so special that we cannot deal with it from generic code? >>>>>> In particular we do have the REE pass, why is target specific >>>>>> knowledge neccessary >>>>>> to eliminate the extension? >>>>>> >>>>> >>>>> For returning bool values and comparision with integers generates the following by all the rtl passes. >>>>> >>>>> set compare (subreg) >>>>> set if_then_else >>>>> Convert SImode -> QImode >>>>> set zero_extend to SImode from QImode >>>>> set return value 0 in one path of cfg. >>>>> set return value 1 in other path of cfg. >>>>> >>>>> This pass replaces the above zero extension and conversion from QImode to DImode with copy operation to keep QImode in 64 bit registers in powerpc target. >>>> >>>> Sorry, I can't parse that - as there's no testcase with the patch I >>>> cannot even try to see what the actual RTL >>>> looks like (without the pass). >>>> >>> >>> Here is the PR with bugzilla. >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103784 >>> >>> I can add the attached testcase with this PR in the patch. >> >> I don't see any zero-extends there. >> > > Here is the testcase. > > > bool (int a, int b) > { > if (a > 2) > return false; > if (b < 10) > return true; > return false; > } > > compiled with gcc -O3 -m64 testcase.cc -mcpu=power9 -save-temps. > > Here is the rtl after cse. > (note 12 11 15 3 [bb 3] NOTE_INSN_BASIC_BLOCK) > (insn 15 12 16 3 (set (reg:CC 123) > (compare:CC (subreg/s/u:SI (reg/v:DI 120 [ b ]) 0) > (const_int 9 [0x9]))) "ext.cc":5:5 796 {*cmpsi_signed} > (expr_list:REG_DEAD (reg/v:DI 120 [ b ]) > (nil))) > (insn 16 15 17 3 (set (reg:SI 124) > (const_int 1 [0x1])) "ext.cc":5:5 555 {*movsi_internal1} > (nil)) > (insn 17 16 18 3 (set (reg:SI 122) > (if_then_else:SI (gt (reg:CC 123) > (const_int 0 [0])) > (const_int 0 [0]) > (reg:SI 124))) "ext.cc":5:5 344 {isel_cc_si} > (expr_list:REG_DEAD (reg:SI 124) > (expr_list:REG_DEAD (reg:CC 123) > (nil)))) > (insn 18 17 32 3 (set (reg:QI 117 [ _1 ]) > (subreg:QI (reg:SI 122) 0)) "ext.cc":5:5 562 {*movqi_internal} > (expr_list:REG_DEAD (reg:SI 122) > (nil))) > ; pc falls through to BB 5 > (code_label 32 18 31 4 3 (nil) [1 uses]) > (note 31 32 5 4 [bb 4] NOTE_INSN_BASIC_BLOCK) > (insn 5 31 19 4 (set (reg:QI 117 [ _1 ]) > (const_int 0 [0])) "ext.cc":4:16 562 {*movqi_internal} > (nil)) > (code_label 19 5 20 5 2 (nil) [0 uses]) > (note 20 19 21 5 [bb 5] NOTE_INSN_BASIC_BLOCK) > (insn 21 20 22 5 (set (reg:DI 126 [ _1 ]) > (zero_extend:DI (reg:QI 117 [ _1 ]))) "ext.cc":8:1 5 {zero_extendqidi2} > (expr_list:REG_DEAD (reg:QI 117 [ _1 ]) > (nil))) > (insn 22 21 26 5 (set (reg:DI 118 [ ]) > (reg:DI 126 [ _1 ])) "ext.cc":8:1 681 {*movdi_internal64} > (expr_list:REG_DEAD (reg:DI 126 [ _1 ]) > (nil))) > (insn 26 22 27 5 (set (reg/i:DI 3 3) > (reg:DI 126 [ _1 ])) "ext.cc":8:1 681 {*movdi_internal64} > (expr_list:REG_DEAD (reg:DI 118 [ ]) > (nil))) > (insn 27 26 0 5 (use (reg/i:DI 3 3)) "ext.cc":8:1 -1 > (nil)) This looks like it'd be better addressed in REE. We've got two paths to the zero_extend. One sets (reg 117) from a constant. The other sets (reg 117) from a (subreg:QI (reg:SI)). Handling the constant is trivial. For the other set, we can replace the subreg with the zero_extend. Presumably we'd then proceed to try and eliminate the zero-extend by realizing both arms of the conditional move are constants and thus trivially handled. While I don't think REE would handle all this today, fixing it to handle this case seems like it'd be better than doing a specialized pass in the ppc backend. jeff