From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1498 invoked by alias); 5 Feb 2015 07:27:18 -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 1387 invoked by uid 48); 5 Feb 2015 07:27:14 -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: Thu, 05 Feb 2015 07:27: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-02/txt/msg00420.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 --- Comment #33 from amker at gcc dot gnu.org --- (In reply to Richard Biener from comment #32) > "So I take the other way around by passing the IV's ssa_name into > scev_probably_wraps_p along call sequence > "idx_find_step->convert_affine_scev->scev_probably_wraps". Since the IV's > ssa_name is tagged with right range information, we can use it when proving > there is no overflow/wrap in src scev." > > I'm not sure that this is always correct - is the name we ask > scev_probably_wraps > on always equal to the IV? Is it never offsetted? I think that we need a > soultion that involves tracking of range information all the way through > SCEV analysis and thus have it on the CHREC itself. Yes this is wanted, but I think it's another improvement. In IVOPT, we don't need to inherit range information from CHREC from SCEV. The structure iv has field ssa_name pointing to the ssa var. We can use this var's range information in IVOPT. Well, the only problem is that field is reset in record_use. Moreover, for this PR, it isn't range information of IV's var that we want. What we want is the range information of IV's base var. As in below dump: : # RANGE [0, 10] NONZERO 15 # d_26 = PHI # RANGE [0, 9] NONZERO 15 d_13 = d_26 + -1; _14 = A[d_26]; # RANGE [0, 255] NONZERO 255 _15 = (int) _14; # USE = nonlocal # CLB = nonlocal foo (_15); if (d_13 != 0) goto ; else goto ; : goto ; We really want to take advantage of i_6(D)'s range information, which isn't an IV. And it's possible the range information of i_6(D) may not hold in other part of code other than this loop. I had patches for last two issues, will send for review later. > > > As for the other things - yes, there are multiple places where we lose sign > information and STEP is just one example (I _think_ I made DR_STEP for > data-ref analysis forced signed at some point). > > Promoting the array index to a word_mode type sounds interesting, it of > course > only makes sense for previously signed types - otherwise you just get another > conversion in the way. Of course with GCC you will likely run into the issue > that this promotion is cancelled by the forced conversion to sizetype, so > you'll end up with unsigned word_mode again. Btw - this was kind of my > suggestion with making get_inner_reference return *POFFSET as ssizetype type, > not sizetype (callers might not expect this, so for experimenting just > wrap get_inner_reference in sth converting that back to sizetype for all > callers but IVOPTs and tree-affine.c (and eventually > tree-scalar-evolution.c)). I now don't think this PR is caused by the different type precision issue. However it's related to type conversion and how SCEV handles it in GCC. I need more study to fully understand the issue, so shouldn't saying too much in case it's wrong...