From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20673 invoked by alias); 17 Nov 2009 15:54:59 -0000 Received: (qmail 20659 invoked by uid 22791); 17 Nov 2009 15:54:57 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from nikam-dmz.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 17 Nov 2009 15:53:53 +0000 Received: from localhost (campfire.ms.mff.cuni.cz [195.113.18.99]) by nikam.ms.mff.cuni.cz (Postfix) with ESMTP id 18C4C9AC924; Tue, 17 Nov 2009 16:53:51 +0100 (CET) Received: by localhost (Postfix, from userid 29025) id EE13AE33D1; Tue, 17 Nov 2009 16:53:50 +0100 (CET) Date: Tue, 17 Nov 2009 16:03:00 -0000 From: Zdenek Dvorak To: Richard Guenther Cc: Ulrich Weigand , gcc-patches@gcc.gnu.org Subject: Re: [patch] Fix regression (Re: Fix PR tree-optimization/41857) Message-ID: <20091117155350.GA29870@kam.mff.cuni.cz> References: <20091102093837.GA21250@kam.mff.cuni.cz> <200911162005.nAGK5QrA031019@d12av02.megacenter.de.ibm.com> <84fc9c000911170731nee9129m78d778237b3db626@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84fc9c000911170731nee9129m78d778237b3db626@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2009-11/txt/msg00868.txt.bz2 Hi, > > Tested on s390-ibm-linux and spu-elf with no regressions. > > OK for mainline? > > Ugh. Well, good enough for now :( > > I think TMR is broken as it basically treats the base pointer > as "value" compared to everywhere else where pointers have > semantics attached (like target type, ref-all status, etc.). I think you paint TMRs too much evil. It's whole point is to be a lower-level representation of memory access, corresponding to the addressing modes available on the target. Thus, you should expect to lose some information in the lowering. I think part of the problem is that TMR and higher-level representation of memory accesses are used at the same time, thus confusing the expectations. It might be better to lower all memory references to TMRs at some point, to make the separation clear. Anyway, > Thus, TMR misses 1) alignment, I don't see how TMR misses alignment information any more than the original memory access did. > 2) TBAA info, 3) a working way to query points-to info, This is IMHO because we store TBAA + points-to information in a wrong way (associated with the pointers, rather than with the memory references; and in a language-dependent form). > 4) a way to recover a base pointer from TMR_ORIGINAL. Why would you want to do that? > For 4.6 I hope we can dump TMRs alltogether. How do you plan to represent the choices ivopts mades (taking the addressing modes into account)? Without a gimple-level representation of addressing modes, the only option I see is moving the induction variable optimizations to RTL, which would be somewhat difficult, Zdenek