From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14554 invoked by alias); 26 Jan 2015 14:53:39 -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 14336 invoked by uid 55); 26 Jan 2015 14:53:23 -0000 From: "rguenther at suse dot de" 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:53: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: rguenther at suse dot de 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/msg02890.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 --- Comment #22 from rguenther at suse dot de --- On Mon, 26 Jan 2015, amker at gcc dot gnu.org wrote: > 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. Well, it's not sure that relaxing POINTER_PLUS_EXPR will help in the end... > 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? Might be - but it's a matter of fixing the observable regression ;)