From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2161 invoked by alias); 19 Jan 2004 19:39:28 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 2145 invoked from network); 19 Jan 2004 19:39:25 -0000 Received: from unknown (HELO atrey.karlin.mff.cuni.cz) (195.113.31.123) by sources.redhat.com with SMTP; 19 Jan 2004 19:39:25 -0000 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 4018) id 0234A4C0001; Mon, 19 Jan 2004 20:39:25 +0100 (CET) Date: Mon, 19 Jan 2004 19:39:00 -0000 From: Jan Hubicka To: Marc Espie Cc: Jan Hubicka , gcc@gcc.gnu.org Subject: Re: gcc 3.5 integration branch proposal Message-ID: <20040119193924.GB8495@atrey.karlin.mff.cuni.cz> References: <20040110154129.GA28152@disaster.jaj.com> <1073935323.3458.42.camel@minax.codesourcery.com> <1073951351.3458.162.camel@minax.codesourcery.com> <20040119034216.0593F48A4@quatramaran.ens.fr> <200401190349.i0J3nUT22886@makai.watson.ibm.com> <20040119132847.GA16721@tetto.gentiane.org> <20040119133501.GJ31365@atrey.karlin.mff.cuni.cz> <20040119185057.GA6787@tetto.gentiane.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040119185057.GA6787@tetto.gentiane.org> User-Agent: Mutt/1.5.4i X-SW-Source: 2004-01/txt/msg01356.txt.bz2 > On Mon, Jan 19, 2004 at 02:35:01PM +0100, Jan Hubicka wrote: > > > On Sun, Jan 18, 2004 at 10:49:30PM -0500, David Edelsohn wrote: > > > > > > > Did you build head configured with --disable-checking? > > > > > > Rebuilt with --disable-checking, and double-checked the options. There > > > was a bug that meant I was not -O2 in both cases. > > > > > > Now, the actual options are > > > -Wall -Wstrict-prototypes -Wmissing-prototypes > > > -Wno-uninitialized -Wno-format -Wno-main -fno-builtin-printf > > > -fno-builtin-log -fno-builtin-malloc -O2 -fno-strict-aliasing > > > in both cases. > > > > > > And it's still a bit slower: > > > > > > gcc 3.3.2: > > > 527.98s real 421.02s user 30.36s system > > > > > > gcc -head with --disable-checking: > > > 544.91s real 439.52s user 30.27s system > > > > > > > > > Okay, the slow-down is not as marked as with --enable-checking, but it > > > still does exist: 4% is something. > > > > You may consider using profiledbootstrap. It makes bootstrap slower, > > but it pays back in compilation time later. > > 2 hours of whole build may already make it pay back. In fact I would be > > extremly curious about that. > > Yep, profiledbootstrap is very, very slow, but the results are a little > encouraging: > > 515.03s real 389.54s user 30.42s system > > So, it is slightly faster than 3.3.2... > > I'll try doing some profiling for you guys, and building a complete archive > that you can experiment with. > > Now, for the killer question: assuming the OpenBSD project, at some point, > moves to a recent gcc, we might want to have profile-directed compilation, > but we definitely can't afford to run a full profiledbootstrap each time. > > Is the format of profile information such that, say, it could be stored > in arch-dependent directories, and then used for the compilation ? No, actually the format is specific to even compiler settings. This is because the profile can be read back to the compiler and can not be addressed before tree-SSA is accepted. It is however possible to make profledbootstrap faster with some effort. At the moment we build all target libraries with profiling that has relatively huge overhead especially for libjava. We can try to put together smaller testsuite, as the size of train set is usually not important. My experience is that C frontend works well when profilebootstrapped only for C language where train run happens only for libgcc that is very small and specific piece of code, so I would assume that simple tests would be enough. My original implementation of profiledbootstrap were mostly to test the feature and thus I preferred when it is executed heavilly (doing so motivated many optimization to the profiling mechanizm itself), but perhaps it is good idea to revisit it. It makes three stages - stage1 and stage1 is used to build both the compiler used to produce feedback and the compiler to using the feedback. This shall not be much slower than usual 3 stage bootstrap then. Only disadvantage is that feedback stage (equivalent of stage3) is built with non-optimizer stage1 compiler. If frontend maintainers propose some smaller train runs, we can try to put together this plan. > > I'm asking this, because I had to kill one profiledbootstrap, and when > I tried to resume it, it didn't work and told me I had used the wrong > options. This is not supposed to happen as long as you didn't changed your tree. I sometimes re-do make profilebootstrap after stopping it by ctrl+c and it seems to work, so I would be interested knowing more details if you run into this problem again. Honza