From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 6E0403858433; Tue, 27 Feb 2024 14:19:02 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6E0403858433
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1709043542;
	bh=7Hs3gbC0QHpg1EhKwshfbaohhnzB7GeXL4tjaDPxJV0=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=W1uouW4ymFWPw9YFlz+r5ecbg5qoksADlvyrnv6WclWGv8NIT86rNLDZEaIXHLRfi
	 SSSK7dZeOdtoap+YBt3uMbBQRRBCQiM7Gm3LzRv5pGRZ4i1O6KWbp+YiAUVGv3Z6Ef
	 oq0Y4zXwabkyiBqOOp/cAfKki1JG7co3B1uEJS6s=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/114121] wrong code with _BitInt() arithmetics
 at -O2
Date: Tue, 27 Feb 2024 14:19:02 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-114121-4-z9gJV5TW6B@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-114121-4@http.gcc.gnu.org/bugzilla/>
References: <bug-114121-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114121

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #10)
> Could we for lookups if range isn't a subset of the found range pretend
> there was not a match, try to see through definitions again and only if it
> yields an equivalent result value range it the same?  Perhaps even rememb=
er
> the range used in it and in case we find non-subset lookup having the same
> result union the remembered range?

So pretend we record the first match with using a range that improves
the result in the hashtable.  Then, when looking up the second ref we
hit the hashtable entry, see it has an incompatible range so we can't
use the recorded value.  We can then easily only ignore the entry (the
prototype patch does this).  As we can't easily tell whether we used any
(or even which) range without doing multiple lookups for each ref and
comparing the result "re-doing" things wouldn't work.

But for determining two refs are equivalent it might be enough to avoid
recording any kind of range for when the value was "varying".  The value
of such hashtable entry would be usable even by lookups with narrower
range (but also not yielding any better "constant" value).

I'm trying to improve things this way.=