From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by sourceware.org (Postfix) with ESMTPS id B9F9C3858D20 for ; Wed, 31 May 2023 06:02:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B9F9C3858D20 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-x1032.google.com with SMTP id 98e67ed59e1d1-2563ca70f64so3043073a91.0 for ; Tue, 30 May 2023 23:02:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685512941; x=1688104941; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=02xqLAY3TyLYgnuXWa6WiNeNR2NRD70OHS9JZ4dh4Z4=; b=Q49iJ48Dv07r0ht5pcXrE5p3hjC8QEHEKbwKA8nMkbRmrPQaswUoEvE7nEJrrngPBK NLVxcAuaF3bFiGpNiEwkZGkiKlGrF4kkw2srbFBuHIUabDuq3xBKSuyytgWFxBiEnoqd xIgCgRTyDGMIHys1a26+JXfKRqXQWV6dNBYzV7aefMggZaW751wqD9pC7HbknAvVuhXe rN/nVqMpen/hJ7FCEvx1Kd+H67y2FL/EFrplf+vICR64gY5RPHLlcSUFsLT9WOIhwPnI Q/B1/XinZ9S3P4LNN5YKIcgLgL6QdJ/M5TIy3xsVAqxOxP/J+jRxEAqlm5KtEJfsrU91 Ta7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685512941; x=1688104941; h=content-transfer-encoding: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=02xqLAY3TyLYgnuXWa6WiNeNR2NRD70OHS9JZ4dh4Z4=; b=iHzqknXiHs2Nwct70k7gaGatQ0+JCPu0Q0Xz2vaDkaRnNv53JbS3E3pOW5OMzdb2n1 upHav27YLLiXyH9m7CcietFcB/S4+582SgPRtq14RjeTUf/RwwB6/w4iPKITCzbqOqYI 5LSqOdxXxt2mZfXlEDn6kWNDBWIZFlZgVoNT8MEf1mHzDujPbSrdzEP0SWGwhlGlPKG3 n6Nogl5jrAi6VQV9eFTg6GCaKxnNZ2biR8UuA4GH1q5Am3DMerRaKHVDU7rlP0Er+qy5 ksQk7VwgcQ8tOw7NVKnGBJH/dhEx5CDEETjqOzrwvjw5geCaYY1KPoMqKFmv3DJVBBQi MVSA== X-Gm-Message-State: AC+VfDxeHh011IC/i19Sr3V49Nspt2qlTRhyt+Me5x0+Im/gfjvdneZg rsRUuvTZG7uD1gVhDWSzXiFy7RFrQCstlAublT4= X-Google-Smtp-Source: ACHHUZ7NfflYyDpuWKdmhe3jtRjRcs6kIgZGr7KkFKiSMsjpjaPT28G0xJDvWUUPx4psCZmwgKxvdLjflFUdiI6dSOc= X-Received: by 2002:a17:90b:1bd1:b0:253:7ddd:d07b with SMTP id oa17-20020a17090b1bd100b002537dddd07bmr4173750pjb.14.1685512941459; Tue, 30 May 2023 23:02:21 -0700 (PDT) MIME-Version: 1.0 References: <95b8b130-caef-12c8-b247-25ec7dbf0ac3.ref@yahoo.co.jp> <95b8b130-caef-12c8-b247-25ec7dbf0ac3@yahoo.co.jp> In-Reply-To: <95b8b130-caef-12c8-b247-25ec7dbf0ac3@yahoo.co.jp> From: Max Filippov Date: Tue, 30 May 2023 23:02:10 -0700 Message-ID: Subject: Re: [PATCH 2/3 v2] xtensa: Add 'adddi3' and 'subdi3' insn patterns To: "Takayuki 'January June' Suwa" Cc: GCC Patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,FROM_LOCAL_NOVOWEL,GIT_PATCH_0,HK_RANDOM_ENVFROM,HK_RANDOM_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 Tue, May 30, 2023 at 2:50=E2=80=AFAM Takayuki 'January June' Suwa wrote: > > Resubmitting the correct one due to a mistake in merging order of fixes. > --- > More optimized than the default RTL generation. > > gcc/ChangeLog: > > * config/xtensa/xtensa.md (adddi3, subdi3): > New RTL generation patterns implemented according to the instruc- > tion idioms described in the Xtensa ISA reference manual (p. 600)= . > --- > gcc/config/xtensa/xtensa.md | 52 +++++++++++++++++++++++++++++++++++++ > 1 file changed, 52 insertions(+) > > diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md > index eda1353894b..6882baaedfd 100644 > --- a/gcc/config/xtensa/xtensa.md > +++ b/gcc/config/xtensa/xtensa.md > @@ -190,6 +190,32 @@ > (set_attr "mode" "SI") > (set_attr "length" "3")]) > > +(define_expand "adddi3" > + [(set (match_operand:DI 0 "register_operand") > + (plus:DI (match_operand:DI 1 "register_operand") > + (match_operand:DI 2 "register_operand")))] > + "" > +{ > + rtx lo_dest, hi_dest, lo_op0, hi_op0, lo_op1, hi_op1; > + rtx_code_label *label; > + lo_dest =3D gen_lowpart (SImode, operands[0]); > + hi_dest =3D gen_highpart (SImode, operands[0]); > + lo_op0 =3D gen_lowpart (SImode, operands[1]); > + hi_op0 =3D gen_highpart (SImode, operands[1]); > + lo_op1 =3D gen_lowpart (SImode, operands[2]); > + hi_op1 =3D gen_highpart (SImode, operands[2]); > + if (rtx_equal_p (lo_dest, lo_op1)) > + FAIL; With this condition I see the following source unsigned long long foo(unsigned long long a, unsigned long long b) { return a + b; } turns to (expected) .global foo .type foo, @function foo: add.n a2, a2, a4 add.n a3, a3, a5 bgeu a2, a4, .L2 addi.n a3, a3, 1 .L2: ret.n but unsigned long long foo(unsigned long long a, unsigned long long b) { return b + a; } has an extra instruction: .global foo .type foo, @function foo: mov.n a9, a2 add.n a2, a4, a2 add.n a3, a5, a3 bgeu a2, a9, .L2 addi.n a3, a3, 1 .L2: ret.n I though that maybe the following would help (plus using lo_cmp in the emit_cmp_and_jump_insns below): if (!rtx_equal_p (lo_dest, lo_op0)) lo_cmp =3D lo_op0; else if (!rtx_equal_p (lo_dest, lo_op1)) lo_cmp =3D lo_op1; else FAIL; but to my surprise it doesn't. > + emit_clobber (operands[0]); Why is this clobber needed? > + emit_insn (gen_addsi3 (lo_dest, lo_op0, lo_op1)); > + emit_insn (gen_addsi3 (hi_dest, hi_op0, hi_op1)); > + emit_cmp_and_jump_insns (lo_dest, lo_op1, GEU, const0_rtx, > + SImode, true, label =3D gen_label_rtx ()); > + emit_insn (gen_addsi3 (hi_dest, hi_dest, const1_rtx)); > + emit_label (label); > + DONE; > +}) > + > (define_insn "addsf3" > [(set (match_operand:SF 0 "register_operand" "=3Df") > (plus:SF (match_operand:SF 1 "register_operand" "%f") > @@ -237,6 +263,32 @@ > (const_int 5) > (const_int 6)))]) > > +(define_expand "subdi3" > + [(set (match_operand:DI 0 "register_operand") > + (minus:DI (match_operand:DI 1 "register_operand") > + (match_operand:DI 2 "register_operand")))] > + "" > +{ > + rtx lo_dest, hi_dest, lo_op0, hi_op0, lo_op1, hi_op1; > + rtx_code_label *label; > + lo_dest =3D gen_lowpart (SImode, operands[0]); > + hi_dest =3D gen_highpart (SImode, operands[0]); > + lo_op0 =3D gen_lowpart (SImode, operands[1]); > + hi_op0 =3D gen_highpart (SImode, operands[1]); > + lo_op1 =3D gen_lowpart (SImode, operands[2]); > + hi_op1 =3D gen_highpart (SImode, operands[2]); > + if (rtx_equal_p (lo_op0, lo_op1)) > + FAIL; I believe that for the emit_cmp_and_jump_insns below the check here should look like this: if (rtx_equal_p (lo_dest, lo_op0) || rtx_equal_p (lo_dest, lo_op1)) But maybe drop this check and use the following instead? emit_insn (gen_subsi3 (hi_dest, hi_op0, hi_op1)); emit_cmp_and_jump_insns (lo_op0, lo_op1, GEU, const0_rtx, SImode, true, label =3D gen_label_rtx ()); emit_insn (gen_addsi3 (hi_dest, hi_dest, constm1_rtx)); emit_label (label); emit_insn (gen_subsi3 (lo_dest, lo_op0, lo_op1)); > + emit_clobber (operands[0]); Why is this clobber needed? > + emit_insn (gen_subsi3 (lo_dest, lo_op0, lo_op1)); > + emit_insn (gen_subsi3 (hi_dest, hi_op0, hi_op1)); > + emit_cmp_and_jump_insns (lo_op0, lo_op1, GEU, const0_rtx, > + SImode, true, label =3D gen_label_rtx ()); > + emit_insn (gen_addsi3 (hi_dest, hi_dest, constm1_rtx)); > + emit_label (label); > + DONE; > +}) > + > (define_insn "subsf3" > [(set (match_operand:SF 0 "register_operand" "=3Df") > (minus:SF (match_operand:SF 1 "register_operand" "f") > -- > 2.30.2 --=20 Thanks. -- Max