From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4592 invoked by alias); 17 Nov 2009 16:06:05 -0000 Received: (qmail 4485 invoked by uid 22791); 17 Nov 2009 16:06:03 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-pz0-f203.google.com (HELO mail-pz0-f203.google.com) (209.85.222.203) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 17 Nov 2009 16:04:59 +0000 Received: by pzk41 with SMTP id 41so78647pzk.0 for ; Tue, 17 Nov 2009 08:04:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.161.15 with SMTP id j15mr550550rve.226.1258473898235; Tue, 17 Nov 2009 08:04:58 -0800 (PST) In-Reply-To: <20091117155350.GA29870@kam.mff.cuni.cz> References: <20091102093837.GA21250@kam.mff.cuni.cz> <200911162005.nAGK5QrA031019@d12av02.megacenter.de.ibm.com> <84fc9c000911170731nee9129m78d778237b3db626@mail.gmail.com> <20091117155350.GA29870@kam.mff.cuni.cz> Date: Tue, 17 Nov 2009 16:14:00 -0000 Message-ID: <84fc9c000911170804tf086c21r945ef82971ff58de@mail.gmail.com> Subject: Re: [patch] Fix regression (Re: Fix PR tree-optimization/41857) From: Richard Guenther To: Zdenek Dvorak Cc: Ulrich Weigand , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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/msg00870.txt.bz2 On Tue, Nov 17, 2009 at 4:53 PM, Zdenek Dvorak wr= ote: > Hi, > >> > Tested on s390-ibm-linux and spu-elf with no regressions. >> > OK for mainline? >> >> Ugh. =A0Well, 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. =A0It's whole point is to be > a lower-level representation of memory access, corresponding to > the addressing modes available on the target. =A0Thus, you should > expect to lose some information in the lowering. But then why try so hard and preserve TMR_ORIGINAL at all? > 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 expectation= s. > 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 origin= al > memory access did. Fair enough - we do have standard means to extract alignment from memory reference trees though, but not for TMRs (same for other standard means to query properties about memory references - see how the alias-oracle is complicated by TMRs). >> 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; an= d in a > language-dependent form). I agree, TBAA should be with the memory access (like we have on RTL). But points-to information inherently is associated with a pointer. Of course we can stick it onto a memory reference as well if we like to. >> 4) a way to recover a base pointer from TMR_ORIGINAL. > > Why would you want to do that? Because of the way TMRs are translated to RTL MEM_REFs. >> For 4.6 I hope we can dump TMRs alltogether. > > How do you plan to represent the choices ivopts mades (taking the address= ing modes > into account)? =A0Without a gimple-level representation of addressing mod= es, the only > option I see is moving the induction variable optimizations to RTL, which= would be > somewhat difficult, I am toying with the idea to move ivopts right before expansion. That would also keep the passes that are now inbetween ivopts and expansion happy instead of punting on all TMRs. Of course a clear point of lowering our gimple form is ok with me as well, just then we should drop this TMR_ORIGINAL stuff. The middle-end alias-oracle part of the RTL oracle could very well deal with a TMR as MEM_EXPR, but the RTL part does not. Thus, it all needs a little TLC, too late for 4.5. Richard.