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 [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 8500E3858D20 for ; Thu, 29 Feb 2024 10:34:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8500E3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 8500E3858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709202881; cv=none; b=V+hag+Bjn9nW00jTrn+r39/Hmz0345E2mVU1Z8yUcRKbdVBDF3Evdug9r8gUpESfTA8+xd42GsfhPSb2dIrVGz+S7pEj9l6RQ86E6vKcaDT4QlzPUrwIJqAZWmkWXq99l5Fda88PVqptxZEPq5Rx/fKBNwp/dqytqmY0zdJN/nI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709202881; c=relaxed/simple; bh=dkqfGezPqpMRhb2X8xqj9LY75RSnDWVaTcMqBZnHPO0=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=Ua/aZadDvsEunrj4FfkHRrumFZHSR2A4wJmOrpF5ul8zd4Zm1DSw+uUggnsvccVkET9VJEKZ1kTYoW1wMqro5gcKc/UTb6yz0P7R6RuyJ173mXarkvhhKDI8chqH6CKiarMzBEU55tKibpTqIRgIZ6QEexvPVByaO44vizEclFA= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709202879; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=4TWXn3wvLp+gZBxzTHWOctyqEwZx5SUIvwyp3A7uCTo=; b=IBDuoxSN0iRLiaB/z9bV+fKyFjXgVhRoilcn2Wp8/ZxoehTKwpvdaNRYVKeI5jpj19rj65 N0NF+k/aAjIWDWYBpghVflZUJM2ot0hBlpZOqrvBb3HKyIxWuYYPJL2T0jdZyi+zv2TvrE VHYwInwMZGbSrk2QFzISw5DqbcBNhjo= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-557-ELlcfZTmNfqZTskVyFxQZw-1; Thu, 29 Feb 2024 05:34:37 -0500 X-MC-Unique: ELlcfZTmNfqZTskVyFxQZw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 52CEA185A781; Thu, 29 Feb 2024 10:34:37 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.25]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0C13E1121312; Thu, 29 Feb 2024 10:34:36 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 41TAYYUO1800603 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 29 Feb 2024 11:34:34 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 41TAYXrr1800600; Thu, 29 Feb 2024 11:34:33 +0100 Date: Thu, 29 Feb 2024 11:34:32 +0100 From: Jakub Jelinek To: Richard Biener , richard.sandiford@arm.com Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] tree-optimization/114151 - handle POLY_INT_CST in get_range_pos_neg Message-ID: Reply-To: Jakub Jelinek References: <20240229082111.024291329E@imap2.dmz-prg2.suse.org> MIME-Version: 1.0 In-Reply-To: <20240229082111.024291329E@imap2.dmz-prg2.suse.org> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.3 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=-9.5 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_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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 Thu, Feb 29, 2024 at 09:21:02AM +0100, Richard Biener wrote: > The following switches the logic in chrec_fold_multiply to > get_range_pos_neg since handling POLY_INT_CST possibly mixed with > non-poly ranges will make the open-coding awkward and while not > a perfect fit it should work. > > In turn the following makes get_range_pos_neg aware of POLY_INT_CSTs. > I couldn't make it work with poly_wide_int since the compares always > fail to build but poly_widest_int works fine and it should be > semantically the same. I've also changed get_range_pos_neg to > use get_range_query (cfun), problematical passes shouldn't have > a range query activated so it shouldn't make a difference there. > > This doesn't make a difference for the PR but not considering > POLY_INT_CSTs was a mistake. > > Bootstrap and regtest running on x86_64-unknown-linux-gnu, OK? > > Thanks, > Richard. > > PR tree-optimization/114151 > * tree.cc (get_range_pos_neg): Handle POLY_INT_CST, use > the passes range-query if available. > * tree-chre.cc (chrec_fold_multiply): Use get_range_pos_neg > to see if both operands have the same range. > --- > gcc/tree-chrec.cc | 14 ++------------ > gcc/tree.cc | 12 +++++++----- > 2 files changed, 9 insertions(+), 17 deletions(-) > > diff --git a/gcc/tree-chrec.cc b/gcc/tree-chrec.cc > index 2e6c7356d3b..450d018ce6f 100644 > --- a/gcc/tree-chrec.cc > +++ b/gcc/tree-chrec.cc > @@ -442,18 +442,8 @@ chrec_fold_multiply (tree type, > if (!ANY_INTEGRAL_TYPE_P (type) > || TYPE_OVERFLOW_WRAPS (type) > || integer_zerop (CHREC_LEFT (op0)) > - || (TREE_CODE (CHREC_LEFT (op0)) == INTEGER_CST > - && TREE_CODE (CHREC_RIGHT (op0)) == INTEGER_CST > - && (tree_int_cst_sgn (CHREC_LEFT (op0)) > - == tree_int_cst_sgn (CHREC_RIGHT (op0)))) > - || (get_range_query (cfun)->range_of_expr (rl, CHREC_LEFT (op0)) > - && !rl.undefined_p () > - && (rl.nonpositive_p () || rl.nonnegative_p ()) > - && get_range_query (cfun)->range_of_expr (rr, > - CHREC_RIGHT (op0)) > - && !rr.undefined_p () > - && ((rl.nonpositive_p () && rr.nonpositive_p ()) > - || (rl.nonnegative_p () && rr.nonnegative_p ())))) > + || (get_range_pos_neg (CHREC_LEFT (op0)) > + | get_range_pos_neg (CHREC_RIGHT (op0))) != 3) > { > tree left = chrec_fold_multiply (type, CHREC_LEFT (op0), op1); > tree right = chrec_fold_multiply (type, CHREC_RIGHT (op0), op1); So, wouldn't it be better to outline what you have above + POLY_INT_CST handling into a helper function, which similarly to get_range_pos_neg returns a bitmask, but rather than 1 bit for may be [0, max] and another bit for may be [min, -1] you return 3 bits, 1 bit for may be [1, max], another for may be [0, 0] and another for may be [min, -1]? Also, I bet you actually want to handle TREE_UNSIGNED just as [0, 0] and [1, max] ranges unlike get_range_pos_neg. So perhaps int ret = 7; if (TYPE_UNSIGNED (TREE_TYPE (arg))) ret = 3; if (poly_int_tree_p (arg)) { poly_wide_int w = wi::to_poly_wide (arg); if (known_lt (w, 0)) return 4; else if (known_eq (w, 0)) return 2; else if (known_gt (w, 0)) return 1; else return 7; } value_range r; if (!get_range_query (cfun)->range_of_expr (r, arg) || r.undefined_p ()) return ret; if (r.nonpositive_p ()) ret &= ~1; if (r.nonzero_p ()) ret &= ~2; if (r.nonnegative_p ()) ret &= ~4; return ret; ? And then you can use it similarly, ((whatever_fn (CHREC_LEFT (op0)) | whatever_fn (CHREC_RIGHT (op0))) & ~2) != 5 Sure, if it is written just for this case and not other uses, it could be just 2 bits, can contain [1, max] and can contain [min, -1] because you don't care about zero, return 0 for the known_eq (w, 0) there... Though see below, perhaps it should just handle INTEGER_CSTs and is_constant () POLY_INT_CSTs, not really sure what happens if there are overflows in the POLY_INT_CST evaluation. > --- a/gcc/tree.cc > +++ b/gcc/tree.cc > @@ -14408,13 +14408,15 @@ get_range_pos_neg (tree arg) > > int prec = TYPE_PRECISION (TREE_TYPE (arg)); > int cnt = 0; > - if (TREE_CODE (arg) == INTEGER_CST) > + if (poly_int_tree_p (arg)) > { > - wide_int w = wi::sext (wi::to_wide (arg), prec); > - if (wi::neg_p (w)) > + poly_widest_int w = wi::sext (wi::to_poly_widest (arg), prec); > + if (known_lt (w, 0)) > return 2; > - else > + else if (known_ge (w, 0)) > return 1; > + else > + return 3; > } > while (CONVERT_EXPR_P (arg) > && INTEGRAL_TYPE_P (TREE_TYPE (TREE_OPERAND (arg, 0))) I doubt POLY_INT_CST will appear on what the function is being called on (types with scalar integral modes, mainly in .*_OVERFLOW expansion or say division/modulo expansion, but maybe my imagination is limited); so, if you think this is a good idea and the poly int in that case somehow guarantees the existing behavior (guess for signed it would be at least when not -fwrapv in action UB if the addition of the first POLY_INT_CST coeff and the others multiplied by the runtime value wraps around, but for unsigned is there a guarantee that if all the POLY_INT_CST coefficients don't have msb set that the resulting value will not have msb set either? > @@ -14434,7 +14436,7 @@ get_range_pos_neg (tree arg) > if (TREE_CODE (arg) != SSA_NAME) > return 3; > value_range r; > - while (!get_global_range_query ()->range_of_expr (r, arg) > + while (!get_range_query (cfun)->range_of_expr (r, arg) > || r.undefined_p () || r.varying_p ()) > { > gimple *g = SSA_NAME_DEF_STMT (arg); This hunk is certainly ok. Jakub