From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10117 invoked by alias); 26 Jan 2015 14:19:17 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 2941 invoked by uid 48); 26 Jan 2015 14:19:10 -0000 From: "amker at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/62173] [5.0 regression] 64bit Arch can't ivopt while 32bit Arch can Date: Mon, 26 Jan 2015 14:19:00 -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: 5.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: amker at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: jiwang at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-01/txt/msg02883.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 --- Comment #20 from amker at gcc dot gnu.org --- (In reply to Richard Biener from comment #18) > It's probably not correct to simply transfer range info from *idx to > iv->base. > Instead SCEV analysis needs to track the range of CHREC_LEFT when it analyzes > the SSA use-def chain. That's of course a much bigger change :/ > > The patch may still help in some cases - I suppose the original testcase is > reduced from sth else? I see it's a tricky problem, and I have to admit that I don't understand it very well yet. The question is, is relax of POINTER_PLUS_EXPR constraint the right way fixing this? I do remember some other PRs (other than this one or bug 52563) are caused by this constraint according to your comments. Of course, take range information into consideration is always an improvement. Actually I have another possible example in iv elimination. Curently GCC simply rejects elimination of an iv use with a candidate if the cand is of smaller type, but as long as we can prove value of iv use can be represented by the smaller candidate, elimination is actually safe. But seems to me, fixing this issue with value information is like a side-effect?