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.133.124]) by sourceware.org (Postfix) with ESMTPS id 379C33858D28 for ; Mon, 26 Feb 2024 14:46:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 379C33858D28 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 379C33858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708958772; cv=none; b=hTMkubhlAFdeY55RcvDIZaFvmeFkrYssfwQJ4z8kS12o8PkWOJN+pEsb9NjKIwth67u/3YqmzKaMWUy9MdLr/VovTluIEeiKFE5PEU9ayNdRpKS9r22KUyGp7hha9BcVhxk+OaPsk2zHvyRJ7Yi+uYFDrRUr3V/Fy+qt3ZF/ZGo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708958772; c=relaxed/simple; bh=VpKnRr00v4kpmvVAVN2St1IVp0f1FYHA1TbJ7A7DWW8=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=VrVA2cleASfQlQ9fZ19/IP7gteXox3VV0CXF/lk6EMt4+5+btZ5YKUxPQ6rXVESqdhP6M//liwAUI8BElbll1qBwqsdg5i2pEOxOhiJFhDupMuYnoqdBkIfBvK0Glen7OqEU5HmMgFfY677Pc1A9yXYYfcIzBWlPI2FfbIhp950= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1708958763; 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=S/qRPH/dLFz4OxBfnnAZ1d/unxZCwkUHWWxGG/nX5yw=; b=KBmHh18Vqd6GiutpWt7pGh2SfrmDqNUvRbGsaZCE8W1vBR2+8F+0rDUozDvn9p2Blv21s0 GBZO3+jQymv63Xi/uphqYyUDHZv8OvNZOHi/4dYObkjMwP/Kg3u6e6p6+2RdiSPseA2W4Z KNdJOHxVuSVVPXypZxdAXTp5ldq2v8w= 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-340-N0U-fMIiPMmWIVUX_omfCQ-1; Mon, 26 Feb 2024 09:46:00 -0500 X-MC-Unique: N0U-fMIiPMmWIVUX_omfCQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (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 610C285A589; Mon, 26 Feb 2024 14:46:00 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.25]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2504A1C060B1; Mon, 26 Feb 2024 14:46:00 +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 41QEjvig1355014 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 26 Feb 2024 15:45:57 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 41QEjuUu1355013; Mon, 26 Feb 2024 15:45:56 +0100 Date: Mon, 26 Feb 2024 15:45:56 +0100 From: Jakub Jelinek To: Richard Biener Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] tree-optimization/114074 - CHREC multiplication and undefined overflow Message-ID: Reply-To: Jakub Jelinek References: <83476.124022609150401789@us-mta-131.us.mimecast.lan> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 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=-3.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,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 Mon, Feb 26, 2024 at 03:29:30PM +0100, Richard Biener wrote: > On Mon, 26 Feb 2024, Jakub Jelinek wrote: > > > On Mon, Feb 26, 2024 at 03:15:02PM +0100, Richard Biener wrote: > > > When folding a multiply CHRECs are handled like {a, +, b} * c > > > is {a*c, +, b*c} but that isn't generally correct when overflow > > > invokes undefined behavior. The following uses unsigned arithmetic > > > unless either a is zero or a and b have the same sign. > > > > > > I've used simple early outs for INTEGER_CSTs and otherwise use > > > a range-query since we lack a tree_expr_nonpositive_p. > > > > What about testing > > (get_range_pos_neg (CHREC_LEFT (op0)) > > | get_range_pos_neg (CHREC_RIGHT (op0))) != 3 > > ? > > Ah, didn't know about that. It seems to treat zero as "always > positive", so for 0 and -1 I'd get 3. OK as I check for > zero CHREC_LEFT separately. The function has been used where one cares about the possible values of the sign bit, so 0 in that case is 0 sign bit. If you want to differentiate between negative, 0 and positive and allow non-positive with non-positive or non-negative with non-negative together, then it isn't the right function to call (unless we add tracking if the value can be zero, return bitmask with 3 bits rather than 2 and adjust all callers). > I'll note that get_range_pos_neg only asks global range query > and for SSA names (but not sure if range_of_expr handles aribitrary > GENERIC as SCEV tends to have here ...). I think range_of_expr should handle usual GENERIC trees and punt on stuff it doesn't handle. And your patch was using ranger from current pass while get_range_pos_neg uses always the global ranges (it is usually used during expansion where the pass doesn't have its ranger instance). Though, if you don't ask for range on a particular statement, it doesn't really matter and is just a global range query. > Will update the patch, I think any improvement should be done > to get_range_pos_neg (it's a bit odd in behavior for unsigned > but I have only signed things incoming). For unsigned if it always returned 1, it would be quite useless, there would be no point for the caller to call it in that case. Jakub