From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B9A75385B52D; Thu, 23 Mar 2023 17:46:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B9A75385B52D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1679593568; bh=b63/EKQOPkw8MuI8KjsXNbRt7dPq3kPmxHXBGnJN3O4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=qkPey2QbQq9NQBU89X6FgfccqZcu4tN0pG6+2bytpyjX751iJnWtjvn8xDMkWc4qz zTdJZxIG1MMZhmz3XJ5flgUPgMPfTcdirwgyTQQOt4x7Wo0ciX6sv36IsCCwAhrQL2 xqP5nzKoOM8tvRZAf/34wGy13K1jmuqqAcI2aUNQ= From: "amacleod at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: =?UTF-8?B?W0J1ZyB0cmVlLW9wdGltaXphdGlvbi8xMDkyMzhdIFsxMyBSZWdy?= =?UTF-8?B?ZXNzaW9uXSB0c3QtcmVhbGxvYy5pOjQyOjE5OiBlcnJvcjogcG9pbnRlciA=?= =?UTF-8?B?4oCYcOKAmSBtYXkgYmUgdXNlZCBhZnRlciDigJhyZWFsbG9j4oCZIFstV2Vy?= =?UTF-8?B?cm9yPXVzZS1hZnRlci1mcmVlXSBpbiBnbGliYyB0ZXN0cw==?= Date: Thu, 23 Mar 2023 17:46:07 +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: 13.0 X-Bugzilla-Keywords: needs-reduction X-Bugzilla-Severity: normal X-Bugzilla-Who: amacleod at redhat dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109238 --- Comment #6 from Andrew Macleod --- Created attachment 54738 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D54738&action=3Dedit Patch to fix the issue Ah, sorry I missed that. OK, I traced it through. The problem turns out to be in the dom_resolve cod= e. when we are trying to pick up a value via dominators, we walk the dominator chain looking for outgoing edges which change the value and/or existing val= ues. As we find these values, will fill the on-entry cache so that future queri= es will be faster. When we encounter a dominator node that has multiple incoming edges, as BB = 33 does, we separately ask for a "quick" read-only fill and accumulate each incoming edges values. this allows us to pick up things where ranges are adjusted on edges from non-dominator block ie bb2: if (foo) if (a < 10) goto A: else goto B; else if (a >=3D 10) goto C: else goto A: goto D: A: Block A's dominator is bb2. It has 2 predecessors however, and on each of those incoming edges, a has a range of [0, 10]. So by querying the outgoing range of a on each predecessor we come up with [0,10] for a range of A, which would not be possible simply by examining the dominator itself. This query is done in a read-only mode so we dont go polluting the cache wi= th a bunch of things we may not need. Anyway, it all works swimmingly. usually. What happened in this case is BB 33 has 2 predecessors. BB 28 and BB 32. The edge from BB28 correctly picked up the range of ~[0,0], but the query f= or BB32 went wrong. BB32 is a back edge, and the query leads back to BB 33, a= nd in read only mode, we do not deal with these multiple incoming edges.. (and= it avoids an infinite loop).. so that query bails, and we end up with VARYING.= =20 that is what was generating the confusing output: CACHE: BB 32 DOM query for c_24, found [irange] unsigned char * VARYING at = BB28 CACHE: Range for DOM returns : [irange] unsigned char * VARYING CACHE: Range for DOM returns : [irange] unsigned char * VARYING When we are doing this inferior DOM query in read-only like this like this,= we do not need to incorporate anything from a back edge. Its intended to be pulling a value from dominators, and there is no additional information on = that edge. Any values from that edge can only be subsets of what the other inco= ming edges have, and with the results being unioned... its pointless. I have not yet managed to produce a reduced testcase.=