From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-338047-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 20918 invoked by alias); 12 Mar 2013 15:33:49 -0000
Received: (qmail 20909 invoked by uid 22791); 12 Mar 2013 15:33:47 -0000
X-SWARE-Spam-Status: No, hits=-7.5 required=5.0	tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 Mar 2013 15:33:28 +0000
Received: from relay1.suse.de (unknown [195.135.220.254])	by mx2.suse.de (Postfix) with ESMTP id 423FFA50DD;	Tue, 12 Mar 2013 16:33:27 +0100 (CET)
Date: Tue, 12 Mar 2013 15:33:00 -0000
From: Richard Biener <rguenther@suse.de>
To: Steven Bosscher <stevenb.gcc@gmail.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH][6/n] tree LIM TLC
In-Reply-To: <CABu31nN+nC_aUwEbEY9ambq9Facg_X1=W8jC62E38-TNqLfnmw@mail.gmail.com>
Message-ID: <alpine.LNX.2.00.1303121630390.3543@zhemvz.fhfr.qr>
References: <alpine.LNX.2.00.1303121622190.3543@zhemvz.fhfr.qr> <CABu31nN+nC_aUwEbEY9ambq9Facg_X1=W8jC62E38-TNqLfnmw@mail.gmail.com>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
X-SW-Source: 2013-03/txt/msg00439.txt.bz2

On Tue, 12 Mar 2013, Steven Bosscher wrote:

> On Tue, Mar 12, 2013 at 4:25 PM, Richard Biener wrote:
> >
> > (Un-?)surprisingly the most effective compile-time reduction for
> > the testcase in PR39326 is to employ ao_ref caching for
> > alias oracle queries and caching of expanded affine-combinations
> > for affine disambiguations.
> >
> > This reduces compile-time to a manageable amount in the first place
> > for me (so I'm sending it "late" in the series).
> 
> I suppose this renders my LIM patch obsolete.

Not really - it's still

 tree loop invariant motion: 588.31 (78%) usr

so limiting the O(n^2) dependence testing is a good thing.  But I
can take it over from here and implement that ontop of my patches
if you like.

> Did you also look at the memory foot print?

Yeah, unfortunately processing outermost loops separately doesn't
reduce peak memory consumption.  I'll look into getting rid of the
all-refs bitmaps, but I'm not there yet.

Currently the testcase peaks at 1.7GB for me (after LIM, then
it gets worse with DSE and IRA).  And I only tested -O1 sofar.

Thanks,
Richard.