From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) by sourceware.org (Postfix) with ESMTPS id 836C2384F496 for ; Fri, 18 Nov 2022 12:36:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 836C2384F496 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-ed1-x532.google.com with SMTP id y24so1944708edi.10 for ; Fri, 18 Nov 2022 04:36:23 -0800 (PST) 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=RB5qKcMpirpMJ4KvvBHttr1r64qLpnpiveCJZPfdaqo=; b=munz1mqlPKs2U2Bk0FQOseFoVTWS6nCb7pGRlqCrwVNc6pdcbv05fQRoiTcgScSXfw dry6IjQ039xkQzA8FmMYBuxhr1llBMuHenKkrxO8LSdDRpl8rbV4lBSh4CaZJgoUGbPY 4fO7/t7h6ltd1LVzqLAEbQasDgBhYMrTY5iLvpKGSoeEs5LSQ79qstklUzgt5DepVrrN GQqzqvhdd5H5yUiAfkBM1GEvhc06C+tGQGWj4H10uW599G+m8pReNSTFD7hprXO+RjrX wkHEqpkhgYt4o8R9iDo+B6a0Xr57vaMPOtQwy44xg7AeMlaZwXNzFpEAEvE/7XqI/mQY pnPQ== 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=RB5qKcMpirpMJ4KvvBHttr1r64qLpnpiveCJZPfdaqo=; b=hphoLxL7mND3opxb+nMft6hKTyE4Y0rYgAyxgD/oijQnd65ZszRV1de0VjHjMYTl8x VDjWnPpgceDQl77LyTfSEMMcGrPCGpTLVldARXiMlfbMVX6p2gdTt3Q8UhPMfr+hOsz+ DThxhxdaDXmoMVY+pQmWZR7oK5gk326Yue6eMmbfLtrpzbs5qgokdxlSvggk+15476Tp 5wMQOpBBOt8IslZngPJx3+6a5z88JFwIuq/khW5U4tzjSomnX4JW7iS4qQjPie7OWzHl ok9Dihs0NcVG5iP2UmPGyKHm/S+MvP70cqd87hSJFGaM9BmEaBDxJJ4sZsQlNwyt/C6Q 2iVw== X-Gm-Message-State: ANoB5pkBZCrwFBRrXagDrxsCo+lspQUSunBtn9PCsFDWucv7xEyw1wTp V5vwxDAbPnwOjBLcINBb3yZ7Ql39H7OXv6wOm6I= X-Google-Smtp-Source: AA0mqf5XXD6Rz5K6De7ztITs/kjTEwihUuCG6v8+bL9ptGIwVd+LXX5rq7MFSMuU9Vbyc7qx8IZq1GFlyWkDEGZVI5g= X-Received: by 2002:aa7:c98e:0:b0:469:39:1f30 with SMTP id c14-20020aa7c98e000000b0046900391f30mr3444336edt.238.1668774981923; Fri, 18 Nov 2022 04:36:21 -0800 (PST) MIME-Version: 1.0 References: <438c6628-0b9c-e5d0-e198-2fd6edd16a93@linux.ibm.com> <20221118121822.GY25951@gate.crashing.org> In-Reply-To: <20221118121822.GY25951@gate.crashing.org> From: David Edelsohn Date: Fri, 18 Nov 2022 07:36:09 -0500 Message-ID: Subject: Re: [PATCHv2, rs6000] Enable have_cbranchcc4 on rs6000 To: Segher Boessenkool , HAO CHEN GUI Cc: gcc-patches , "Kewen.Lin" , Peter Bergner Content-Type: multipart/alternative; boundary="00000000000001f6e905edbdf470" X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --00000000000001f6e905edbdf470 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Nov 18, 2022 at 7:20 AM Segher Boessenkool < segher@kernel.crashing.org> wrote: > On Fri, Nov 18, 2022 at 02:35:30PM +0800, HAO CHEN GUI wrote: > > =E5=9C=A8 2022/11/17 21:24, David Edelsohn =E5=86=99=E9=81=93: > > > Why are you using zero_constant predicate instead of matching > (const_int 0) for operand 2? > > The "const_int 0" is an operand other than a predicate. We need a > predicate here. > > Said differently, it is passed as an operand to this named pattern or > optab, so you need a match_operand here. > Earlier versions of patterns for other targets used (const_int 0), but they seem to have changed that, so match_operand is needed. Thanks, David > > > > Why does this need the new all_branch_comparison_operator? Can the > ifcvt optimization correctly elide the 2 insn sequence? > > Because rs6000 defines "*cbranch_2insn" insn, such insns are generated > after expand. > > > > (jump_insn 50 47 51 11 (set (pc) > > (if_then_else (ge (reg:CCFP 156) > > (const_int 0 [0])) > > (label_ref 53) > > (pc))) > "/home/guihaoc/gcc/gcc-mainline-base/gmp/mpz/cmpabs_d.c":80:7 884 > {*cbranch_2insn} > > (expr_list:REG_DEAD (reg:CCFP 156) > > (int_list:REG_BR_PROB 633507684 (nil))) > > -> 53) > > But notice the cost of *cbranch_2insn -- ifcvt should never generate > cbranchcc4 with such composite conditions! > > > In prepare_cmp_insn, the comparison is verified by insn_operand_matches. > If > > extra_insn_branch_comparison_operator is not included in "cbranchcc4" > predicate, > > it hits ICE here. > > > > if (GET_MODE_CLASS (mode) =3D=3D MODE_CC) > > { > > enum insn_code icode =3D optab_handler (cbranch_optab, CCmode); > > test =3D gen_rtx_fmt_ee (comparison, VOIDmode, x, y); > > gcc_assert (icode !=3D CODE_FOR_nothing > > && insn_operand_matches (icode, 0, test)); > > *ptest =3D test; > > return; > > } > > > > The real conditional move is generated by emit_conditional_move_1. > Commonly > > "*cbranch_2insn" can't be optimized out and it returns NULL_RTX. > > > > if (COMPARISON_P (comparison)) > > { > > saved_pending_stack_adjust save; > > save_pending_stack_adjust (&save); > > last =3D get_last_insn (); > > do_pending_stack_adjust (); > > machine_mode cmpmode =3D comp.mode; > > prepare_cmp_insn (XEXP (comparison, 0), XEXP (comparison, 1), > > GET_CODE (comparison), NULL_RTX, unsignedp, > > OPTAB_WIDEN, &comparison, &cmpmode); > > if (comparison) > > { > > rtx res =3D emit_conditional_move_1 (target, comparison, > > op2, op3, mode); > > if (res !=3D NULL_RTX) > > return res; > > } > > delete_insns_since (last); > > restore_pending_stack_adjust (&save); > > > > I think that extra_insn_branch_comparison_operator should be included in > > "cbranchcc4" predicates as such insns exist. And leave it to > > emit_conditional_move which decides whether it can be optimized or not. > > I don't think we should pretend we have any conditional jumps the > machine does not actually have, in cbranchcc4. When would this ever be > useful? cror;beq can be quite expensive, compared to the code it would > replace anyway. > > If something generates those here (which then ICEs later), that is > wrong, fix *that*? Is it ifcvt doing it? > > > Segher > --00000000000001f6e905edbdf470--