From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24938 invoked by alias); 17 Dec 2013 15:09:13 -0000 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 Received: (qmail 24923 invoked by uid 89); 17 Dec 2013 15:09:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qc0-f181.google.com Received: from mail-qc0-f181.google.com (HELO mail-qc0-f181.google.com) (209.85.216.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 17 Dec 2013 15:09:10 +0000 Received: by mail-qc0-f181.google.com with SMTP id e9so4881852qcy.40 for ; Tue, 17 Dec 2013 07:09:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kv58PslIQH8nwyhAu2z11hE6Yy+oZ/nUwS/E0m2o7l4=; b=TPIXG7QWt/FhAUc7VzH9M3e3GQaTxSrCW5PEAKqCoH0bCpyptgLPU71zbh05EcCkMR vLqsHVv20vuUcW9RM9wcM6KdYStWuPlaUvjGgiIi4dzaR3EE6pMLz8FsLkbFluhSuFfl pgIbfkZxoqBXN2OsGX5UCydm0m7a7tNlkol3LhynFB8XLS+hvCjmuLGVQN+DplyWkuqh /4gTVQtoeaCVeyET1pdVFUzh9YbR2TsmRV+6Cwi3sNG2hWUSWPlb3SeAE0zYDnpJ6cXr u8aOERmUy0a1iq5d1M9JPIBeOuXgx57djh9GPR0pBdIEAYiDseggK+6OfSx9EYYmSSkf gByQ== X-Gm-Message-State: ALoCoQlKGLna0FfyrNIhLk1HCB+wj71O9GyYiUZIK7iW7RV6vmKJEEmBss6zDRobRRX2xOIz18FZLcgWWzb3v9Txb6c5xDZxAbTucEJJdUTxDHPnTt5FUYck/91UbaySz6lyIiLs0vTS1bfLtLU+zFD1y+Le7FGRe0rqdG+RKpj1B17WcfiONawAULQxMvbNimwLmhLFK5tcCCfLw0dnvq9taf/zMpbvCQ== MIME-Version: 1.0 X-Received: by 10.49.127.101 with SMTP id nf5mr43606918qeb.61.1387292948601; Tue, 17 Dec 2013 07:09:08 -0800 (PST) Received: by 10.229.127.4 with HTTP; Tue, 17 Dec 2013 07:09:08 -0800 (PST) In-Reply-To: References: <528BA299.7040606@redhat.com> <20131128140655.GA20730@kam.mff.cuni.cz> <529CB252.4070806@redhat.com> <20131213011309.GA21107@kam.mff.cuni.cz> Date: Tue, 17 Dec 2013 15:09:00 -0000 Message-ID: Subject: Re: [PATCH i386] Enable -freorder-blocks-and-partition From: Teresa Johnson To: =?UTF-8?Q?Martin_Li=C5=A1ka?= Cc: Jan Hubicka , Jeff Law , "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg01504.txt.bz2 Thanks for the data. A few questions: - Do you have the raw data used to generate your pdfs available? Since you gave me the binaries, if I have the data in terms of exactly what addresses are being plotted I can correlate with the specific cold functions via nm. Once I know what cold functions are being hit, I would then need the .i files and the .gcda files to reproduce the build. - I tried running the binaries, but don't have the necessary shared library dependencies installed on my system: $ ldd gimp-2.8 | grep found libgimpwidgets-2.0.so.0 =3D> not found libgimpconfig-2.0.so.0 =3D> not found libgimpcolor-2.0.so.0 =3D> not found libgimpmath-2.0.so.0 =3D> not found libgimpthumb-2.0.so.0 =3D> not found libgimpmodule-2.0.so.0 =3D> not found libgimpbase-2.0.so.0 =3D> not found libgegl-0.2.so.0 =3D> not found libbabl-0.1.so.0 =3D> not found I'll try to get these installed, but the last time I did that in an attempt to build gimp I had a lot of trouble trying to get the right versions and get them to build for me - any chance you could build an archive version of the gimp binary? Thanks, Teresa On Sun, Dec 15, 2013 at 2:19 PM, Martin Li=C5=A1ka = wrote: > On 15 December 2013 23:17, Martin Li=C5=A1ka wro= te: >> Dear Jan and Teresa, >> Jan was right that I've been using changes which were commited by >> Teresa and do live in trunk. So the graph with time profile presented >> in my previous post was really with enabled >> -freorder-blocks-and-partition. I removed the hack in varasm.c and I >> do use classic section layout. Please open the following dump >> (includes PDF graph+html report that shows functions with time profile >> located in cold section and all -fdump-ipa-all dumps): >> >> https://drive.google.com/file/d/0B0pisUJ80pO1YW1QWUFkZjdqME0/edit?usp=3D= sharing >> >> Apart from that, I created also PDF graph (https://drive.google.com/file= /d/0B0pisUJ80pO1aHhPWW56dXpLVTQ/edit?usp=3Dsharing) that >> shows that time profile is almost perfect for GIMP. I miss just some >> examples that do not have profile in generate phase. >> >> I will merge current trunk and prepare final patch. >> >> Are there any other data that you want to be prepared? >> >> Martin >> >> >> On 13 December 2013 02:13, Jan Hubicka wrote: >>>> On Wed, Dec 11, 2013 at 1:21 AM, Martin Li=C5=A1ka wrote: >>>> > Hello, >>>> > I prepared a collection of systemtap graphs for GIMP. >>>> > >>>> > 1) just my profile-based function reordering: 550 pages >>>> > 2) just -freorder-blocks-and-partitions: 646 pages >>>> > 3) just -fno-reorder-blocks-and-partitions: 638 pages >>>> > >>>> > Please see attached data. >>>> >>>> Thanks for the data. A few observations/questions: >>>> >>>> With both 1) (your (time-based?) reordering) and 2) >>>> (-freorder-blocks-and-partitions) there are a fair amount of accesses >>>> out of the cold section. I'm not seeing so many accesses out of the >>>> cold section in the apps I am looking at with splitting enabled. In >>> >>> I see you already comitted the patch, so perhaps Martin's measurement a= ssume >>> the pass is off by default? >>> >>> I rebuilded GCC with profiledboostrap and with the linkerscript unmappi= ng >>> text.unlikely. I get ICE in: >>> (gdb) bt >>> #0 diagnostic_set_caret_max_width(diagnostic_context*, int) () at ../.= ./gcc/diagnostic.c:108 >>> #1 0x0000000000f68457 in diagnostic_initialize (context=3D0x18ae000 , n_opts=3Dn_opts@entry=3D1290) at ../../gcc/diagn= ostic.c:135 >>> #2 0x000000000100050e in general_init (argv0=3D) at ../= ../gcc/toplev.c:1110 >>> #3 toplev_main(int, char**) () at ../../gcc/toplev.c:1922 >>> #4 0x00007ffff774cbe5 in __libc_start_main () from /lib64/libc.so.6 >>> #5 0x0000000000f7898d in _start () at ../sysdeps/x86_64/start.S:122 >>> >>> That is relatively early in startup process. The function seems inlined= and >>> it fails only on second invocation, did not have time to investigate fu= rther, >>> yet while without -fprofile-use it starts... >>> >>> On our periodic testers I see off-noise improvement in crafty 2200->2300 >>> and regression on Vortex, 2900->2800, plus code size increase. >>> >>> Honza --=20 Teresa Johnson | Software Engineer | tejohnson@google.com | 408-460-2413