From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28643 invoked by alias); 3 Nov 2011 07:52:01 -0000 Received: (qmail 28628 invoked by uid 22791); 3 Nov 2011 07:51:59 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 03 Nov 2011 07:51:46 +0000 From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form. Date: Thu, 03 Nov 2011 07:52: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-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.7.0 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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 X-SW-Source: 2011-11/txt/msg00231.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955 --- Comment #7 from rguenther at suse dot de 2011-11-03 07:51:25 UTC --- On Thu, 3 Nov 2011, duyuehai at gmail dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955 > > --- Comment #6 from Yuehai Du 2011-11-03 06:24:58 UTC --- > Let me see if i understand you correctly, you are saying that there isn't an > easy way to fix it without hurting the performance(either consider less IV > candidates or dumb down the alias analysis). Yes. > so this issue won't be fixed in trunk now? At least I can't see an easy way out. What I was considering as _maybe_ a good final solution would be to remove TARGET_MEM_REF and instead have TARGET_MEM_REF_ADDR, which would produce an SSA name where we could in turn attach alias info to. The minor downside of that is that we lose the ability to directly specify a symbol as the base for a TARGET_MEM_REF (which is ironically exactly the point where things wreck in this testcase ...) > if in that case, Avoiding the issue by set PARM isn't an option for me. i > still want to fix it in our private port even with an ugly patch. can we just > add a new field in MEM_REF which specify it is local or non-nolocal > store(enum{INVALID, LOCAL, NON-LOCAL}), and only set it in IVOPTS before it > rewrite the address. we will check this in is_hidden_global_store(). do this > work in Gimple level? but i don't know if RTL optimization still delete this > store because we don't keep points-to information. The issue is not only in is_hidden_global_store (), but the issue is that alias analysis thinks the store may only alias the local p1 array. Thus you may as well get miscompiles from RTL scheduling as well. You could already paper over the issue in question by checking if a TARGET_MEM_REF has TMR_OFFSET or TMR_OFFSET2 != NULL_TREE in is_hidden_global_store (). Another way would be to make sure we bias costs enough to make the situation less likely, for example in get_computation_cost_at, make the address_p code unconditional.