From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id ECF17390A35E; Thu, 6 Jun 2024 06:40:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ECF17390A35E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1717656016; bh=UxQGAnEESzOOWpjSw53qFyE9MVZ04wwop1u8qIolARE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=FuX79bk0q45LFSXZRAQukSY/57v0fbBBCqmPW8oIrmmEWeItYmzKydR5iHUTANRj3 RMklSTQXFP+emIhmYRPD5R8f73p8b0OpDC5Z9BXcy0jsJd7OJjf98r7iR3l7wwG2gK 7pLAWqt7vir/EyHso0wwD/nyamHJddTgrFGwwKaU= From: "tnfchris at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/114932] IVopts inefficient handling of signed IV used for addressing. Date: Thu, 06 Jun 2024 06:40:16 +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: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: tnfchris at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: tnfchris at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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=3D114932 --- Comment #13 from Tamar Christina --- (In reply to rguenther@suse.de from comment #12)=20 > > since we don't care about overflow here, it looks like the stripping sh= ould > > be recursive as long as it's a NOP expression between two integral type= s. > >=20 > > That would get them to hash to the same IV expression. Trying now.. >=20 > Note tree-affine is a tool that's used for this kind of "weak" equalities. > Convert both to affine, subtract them and if that's zero they are equal. Hmm that's useful, though in this case this becomes the actual expression t= hat IVOpts uses. For instance this is done in alloc_iv and add_iv_candidate_for_use when determining the uses for the IV. It looks like it's trying to force a canonical representation with as minim= um casting as possible. would the "affine"'ed tree be safe to use for this context? What I've done currently is make a STRIP_ALL_NOPS that recursively strips N= OPs for PLUS/MULT/MINUS.=