From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id B7528385841F for ; Sat, 14 Aug 2021 09:16:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B7528385841F Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-391--4pw6AJpNkKlS5Azvh9KyQ-1; Sat, 14 Aug 2021 05:16:50 -0400 X-MC-Unique: -4pw6AJpNkKlS5Azvh9KyQ-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3FF8D801AEB; Sat, 14 Aug 2021 09:16:49 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.193.120]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D2BE060C4A; Sat, 14 Aug 2021 09:16:48 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 17E9GlSR800674 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sat, 14 Aug 2021 11:16:47 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 17E9GfhO800673; Sat, 14 Aug 2021 11:16:41 +0200 Date: Sat, 14 Aug 2021 11:16:41 +0200 From: Jakub Jelinek To: apinski@marvell.com Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Add range/nonzero info to generated ADD_OVERFLOW and simplify Message-ID: <20210814091641.GI2380545@tucnak> Reply-To: Jakub Jelinek References: <1628904168-14894-1-git-send-email-apinski@marvell.com> MIME-Version: 1.0 In-Reply-To: <1628904168-14894-1-git-send-email-apinski@marvell.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-12.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: Sat, 14 Aug 2021 09:16:54 -0000 On Fri, Aug 13, 2021 at 06:22:48PM -0700, apinski--- via Gcc-patches wrote: > From: Andrew Pinski > > Even though this does not change the generated code, > it does improve the initial RTL generation. > > gcc/ChangeLog: > > * tree-ssa-math-opts.c (match_arith_overflow): > Add range and nonzero bits information to > the new overflow ssa name. Also fold > the use statement. > --- > gcc/tree-ssa-math-opts.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/gcc/tree-ssa-math-opts.c b/gcc/tree-ssa-math-opts.c > index c4a6492b50d..bb7edeaa6f7 100644 > --- a/gcc/tree-ssa-math-opts.c > +++ b/gcc/tree-ssa-math-opts.c > @@ -4221,6 +4221,8 @@ match_arith_overflow (gimple_stmt_iterator *gsi, gimple *stmt, > } > } > tree ovf = make_ssa_name (type); > + set_range_info (ovf, VR_RANGE, wi::zero (TYPE_PRECISION (type)), wi::one (TYPE_PRECISION (type))); Too long line. > + set_nonzero_bits (ovf, wi::one (TYPE_PRECISION (type))); Are you sure this is really needed? set_range_info should have computed that one from the range already: /* If it is a range, try to improve nonzero_bits from the min/max. */ if (range_type == VR_RANGE) { wide_int xorv = ri->get_min () ^ ri->get_max (); if (xorv != 0) xorv = wi::mask (precision - wi::clz (xorv), false, precision); ri->set_nonzero_bits (ri->get_nonzero_bits () & (ri->get_min () | xorv)); } > @@ -4279,6 +4281,8 @@ match_arith_overflow (gimple_stmt_iterator *gsi, gimple *stmt, > gimple_assign_set_rhs1 (use_stmt, cond); > } > } > + gimple_stmt_iterator gsi1 = gsi_for_stmt (use_stmt); > + fold_stmt (&gsi1); > update_stmt (use_stmt); I don't think it is safe to do that here. First of all, the update_stmt is right after it, then some further code that still uses use_stmt right below and this is in a loop that iterates imm uses of that use_stmt too. If you want to fold use_stmt, can't it be done after the whole loop? > if (code == MULT_EXPR && use_stmt != orig_use_stmt) > { > -- > 2.27.0 Jakub