From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) by sourceware.org (Postfix) with ESMTPS id 692E83858C2C for ; Wed, 2 Feb 2022 16:51:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 692E83858C2C Received: by mail-wr1-x429.google.com with SMTP id v13so39420768wrv.10 for ; Wed, 02 Feb 2022 08:51:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=G5+BWKu9DvMeG32bhP8V2GhLUaP5a3JQ3HXpjm3+fTE=; b=YzT9iY+84oRAZ1qapfc1TcUHYmGUnidsaZd8gStHdavnbz/wF5oMkPNnuALuML8KAI T0rephn+Cvt9SdiI6zetgqjMajdje/NKCKpekDPfwVeCjG2PbxfgSYNEzFXZ7PaXE9qa Zim/2/uKAip00XHdtzuP2kWxOawUvuNMcVY6dX0J8wvjBosTgeDDKPeKBa8BmHhcAuTw ieDniveNx+XnqqV9xMDxiMAkrVVFQsTIc5GFGTOzNoALpXvDt2W3a2zIQwdkN1mSKwpY ypQ6o/+v2Pvai1StgwTadvl2PG5e9/XyaD29DrHxihP7nPyHO7We1+SYy6Ed9qyOLkdC Pv2g== X-Gm-Message-State: AOAM532XIFSRuHAyP+GemP5reyPm9EhfDRhk+qofO4sspFpUuJ78JjXX dgA9vzoi9Utdt1oNcrnfUvpM73Y+MXZ7FqXYjBt4bLFTaGM= X-Google-Smtp-Source: ABdhPJyXdCn7H/MII4fxtXiJD3RYPg4pQ4kAq6m6NgzMTVH24F/oV8dOGlv8NQn6pYHDUDr9Xq9YsJISvOlqPXyPZLI= X-Received: by 2002:adf:e302:: with SMTP id b2mr25820995wrj.375.1643820695012; Wed, 02 Feb 2022 08:51:35 -0800 (PST) MIME-Version: 1.0 References: <20220113145645.4077141-1-christophe.lyon@foss.st.com> <20220113145645.4077141-8-christophe.lyon@foss.st.com> In-Reply-To: From: Christophe Lyon Date: Wed, 2 Feb 2022 17:51:24 +0100 Message-ID: Subject: Re: [PATCH v3 07/15] arm: Implement MVE predicates as vectors of booleans To: Christophe Lyon via Gcc-patches , Andre Simoes Dias Vieira , Christophe Lyon , Richard Sandiford 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, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2022 16:51:38 -0000 On Tue, Feb 1, 2022 at 4:42 AM Richard Sandiford wrote: > Christophe Lyon via Gcc-patches writes: > > On Mon, Jan 31, 2022 at 7:01 PM Richard Sandiford via Gcc-patches < > > gcc-patches@gcc.gnu.org> wrote: > > > >> Sorry for the slow response, was out last week. > >> > >> Christophe Lyon via Gcc-patches writes: > >> > diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c > >> > index feeee16d320..5f559f8fd93 100644 > >> > --- a/gcc/emit-rtl.c > >> > +++ b/gcc/emit-rtl.c > >> > @@ -6239,9 +6239,14 @@ init_emit_once (void) > >> > > >> > /* For BImode, 1 and -1 are unsigned and signed interpretations > >> > of the same value. */ > >> > - const_tiny_rtx[0][(int) BImode] =3D const0_rtx; > >> > - const_tiny_rtx[1][(int) BImode] =3D const_true_rtx; > >> > - const_tiny_rtx[3][(int) BImode] =3D const_true_rtx; > >> > + for (mode =3D MIN_MODE_BOOL; > >> > + mode <=3D MAX_MODE_BOOL; > >> > + mode =3D (machine_mode)((int)(mode) + 1)) > >> > + { > >> > + const_tiny_rtx[0][(int) mode] =3D const0_rtx; > >> > + const_tiny_rtx[1][(int) mode] =3D const_true_rtx; > >> > + const_tiny_rtx[3][(int) mode] =3D const_true_rtx; > >> > + } > >> > > >> > for (mode =3D MIN_MODE_PARTIAL_INT; > >> > mode <=3D MAX_MODE_PARTIAL_INT; > >> > >> Does this do the right thing for: > >> > >> gen_int_mode (-1, B2Imode) > >> > >> (which is used e.g. in native_decode_vector_rtx)? It looks like it > >> would give 0b01 rather than 0b11. > >> > >> Maybe for non-BImode we should use const1_rtx and constm1_rtx, like wi= th > >> MODE_INT. > >> > > > > debug_rtx ( gen_int_mode (-1, B2Imode) says: > > (const_int -1 [0xffffffffffffffff]) > > so that looks right? > > Ah, right, I forgot that the mode is unused for the small constant lookup= . > But it looks like CONSTM1_RTX (B2Imode) would be (const_int 1) instead, > even though the two should be equal. > Indeed! So I changed the above loop into: /* For BImode, 1 and -1 are unsigned and signed interpretations of the same value. */ for (mode =3D MIN_MODE_BOOL; mode <=3D MAX_MODE_BOOL; mode =3D (machine_mode)((int)(mode) + 1)) { const_tiny_rtx[0][(int) mode] =3D const0_rtx; const_tiny_rtx[1][(int) mode] =3D const_true_rtx; - const_tiny_rtx[3][(int) mode] =3D const_true_rtx; + const_tiny_rtx[3][(int) mode] =3D constm1_rtx; } which works, both constants are now equal and the validation still passes. > >> > @@ -1679,15 +1708,25 @@ emit_class_narrowest_mode (void) > >> > print_decl ("unsigned char", "class_narrowest_mode", > >> "MAX_MODE_CLASS"); > >> > > >> > for (c =3D 0; c < MAX_MODE_CLASS; c++) > >> > - /* Bleah, all this to get the comment right for MIN_MODE_INT. = */ > >> > - tagged_printf ("MIN_%s", mode_class_names[c], > >> > - modes[c] > >> > - ? ((c !=3D MODE_INT || modes[c]->precision !=3D 1) > >> > - ? modes[c]->name > >> > - : (modes[c]->next > >> > - ? modes[c]->next->name > >> > - : void_mode->name)) > >> > - : void_mode->name); > >> > + { > >> > + /* Bleah, all this to get the comment right for MIN_MODE_INT. > */ > >> > + const char *comment_name =3D void_mode->name; > >> > + > >> > + if (modes[c]) > >> > + if (c !=3D MODE_INT || !modes[c]->boolean) > >> > + comment_name =3D modes[c]->name; > >> > + else > >> > + { > >> > + struct mode_data *m =3D modes[c]; > >> > + while (m->boolean) > >> > + m =3D m->next; > >> > + if (m) > >> > + comment_name =3D m->name; > >> > + else > >> > + comment_name =3D void_mode->name; > >> > + } > >> > >> Have you tried bootstrapping the patch on a host of your choice? > >> I would expect a warning/Werror about an ambiguous else here. > >> > > No I hadn't and indeed the build fails > > > >> > >> I guess this reduces to: > >> > >> struct mode_data *m =3D modes[c]; > >> while (m && m->boolean) > >> m =3D m->next; > >> const char *comment_name =3D (m ? m : void_mode)->name; > >> > >> but I don't know if that's more readable. > >> > > but to my understanding the problem is that the ambiguous else > > is the first one, and the code should read: > > if (modes[c]) > > + { > > if (c !=3D MODE_INT || !modes[c]->boolean) > > comment_name =3D modes[c]->name; > > else > > { > > struct mode_data *m =3D modes[c]; > > while (m->boolean) > > m =3D m->next; > > if (m) > > comment_name =3D m->name; > > else > > comment_name =3D void_mode->name; > > } > > + } > > Yeah. I just meant that the alternative loop was probably simpler, > as a replacement for the outer =E2=80=9Cif=E2=80=9D. > > It looks like that the outer =E2=80=9Cif=E2=80=9D is effectively a peeled= iteration of > the while loop in the outer =E2=80=9Celse=E2=80=9D. And the =E2=80=9Cc != =3D MODE_INT=E2=80=9D part ought > to be redundant: as it stands, the boolean modes don't belong to any clas= s. > > Ack, I have now: for (c =3D 0; c < MAX_MODE_CLASS; c++) { /* Bleah, all this to get the comment right for MIN_MODE_INT. */ struct mode_data *m =3D modes[c]; while (m && m->boolean) m =3D m->next; const char *comment_name =3D (m ? m : void_mode)->name; tagged_printf ("MIN_%s", mode_class_names[c], comment_name); } Andre, any chance you tried the suggestion of: ENTRY (Pred1x16_t, V16BI, predicate, 16, pred1, 21) ENTRY (Pred2x8_t, V8BI, predicate, 8, pred1, 21) ENTRY (Pred4x4_t, V4BI, predicate, 4, pred1, 21) Thanks, Christophe > Thanks, > Richard >