From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31317 invoked by alias); 7 Sep 2011 17:01:57 -0000 Received: (qmail 31304 invoked by uid 22791); 7 Sep 2011 17:01:56 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TO_NO_BRKTS_PCNT,TW_LV,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from smtp1.u-psud.fr (HELO smtp1.u-psud.fr) (129.175.33.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 07 Sep 2011 17:01:24 +0000 Received: from smtp1.u-psud.fr (localhost [127.0.0.1]) by localhost (MTA) with SMTP id 26C07255C15 for ; Wed, 7 Sep 2011 19:01:23 +0200 (CEST) Received: from matups.math.u-psud.fr (matups.math.u-psud.fr [129.175.50.4]) by smtp1.u-psud.fr (MTA) with ESMTP id BCEB9255B64 for ; Wed, 7 Sep 2011 19:01:22 +0200 (CEST) Received: from barah.math.u-psud.fr (barah.math.u-psud.fr [129.175.52.24]) by matups.math.u-psud.fr (Postfix) with ESMTP id ABD157234 for ; Wed, 7 Sep 2011 19:01:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by barah.math.u-psud.fr (Postfix) with ESMTP id A7C40474065 for ; Wed, 7 Sep 2011 19:01:22 +0200 (CEST) Received: from barah.math.u-psud.fr ([127.0.0.1]) by localhost (barah.math.u-psud.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbku5LNfHcYk for ; Wed, 7 Sep 2011 19:01:17 +0200 (CEST) Received: from [IPv6:::1] (topodyn-ng.math.u-psud.fr [129.175.50.33]) by barah.math.u-psud.fr (Postfix) with ESMTP id A4D5C474061 for ; Wed, 7 Sep 2011 19:01:16 +0200 (CEST) Message-ID: <4E67A35C.6030800@free.fr> Date: Wed, 07 Sep 2011 17:01:00 -0000 From: Duncan Sands User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110906 Thunderbird/7.0 MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: Re: Comparison of GCC-4.6.1 and LLVM-2.9 on x86/x86-64 targets References: <4E678A9B.3040303@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-09/txt/msg00049.txt.bz2 On 07/09/11 17:55, Xinliang David Li wrote: > Why is lto/whole program mode not used in LLVM for peak performance > comparison? (of course, peak performance should really use FDO..) Assuming Vladimir was using the dragonegg plugin: presumably because it's a pain: you have to compile everything to assembler (-S) rather than to an object file (-c). That's because -flto outputs LLVM IR when used with this plugin, and the system assembler doesn't understand it (and GCC insists on sending output to the system assembler if you pass -c). You then have to convert each .s into a .o (or .bc) using llvm-as. At that point if you have the gold linker and the LLVM linker plugin you can just link using them and you are done. Ciao, Duncan. > > thanks, > > David > > On Wed, Sep 7, 2011 at 8:15 AM, Vladimir Makarov wrote: >> Some people asked me to do comparison of GCC-4.6 and LLVM-2.9 (both >> released this spring) as I did GCC-LLVM comparison in previous year. >> >> You can find it on http://vmakarov.fedorapeople.org/spec under >> 2011 GCC-LLVM comparison tab entry. >> >> >> This year the comparison is done on GCC 4.6 and LLVM 2.9 which were >> released in spring 2011. >> >> As usually I am focused mostly on the compiler comparison >> as *optimizing* compilers on major platform x86/x86-64. I don't >> consider other aspects of the compilers as quality of debug >> information, supported languages, standards and extensions (e.g. OMP), >> supported targets and ABI, support of just-in-time compilation etc. >> >> Different to the 2010 comparison, the SPEC2000 benchmarks were run on >> a recent *Sandy Bridge processor* which will be a mainstream >> processor at least for the next year. >> >> This year I tried to decrease the number of graphs which are still too >> many with my point of view. Some graphs are bigger than for 2010 >> comparison and oriented to screens with a larger resolution. If you >> need exact numbers you should look at the tables from which the graphs >> were generated. >> >> I added GCC run with -O1 which helps to understand >> that *LLVM with -O2 or -O3 is analog of GCC 4.1 with -O1 >> with the point of view of generated code performance and >> compilation speed*. People are frequently saying that LLVM is a much >> faster compiler than GCC. That is probably not true. If you need the same >> generated code quality and compilation speed as LLVM -O2/-O3 >> you should use GCC with -O1. If you want 10%-40% faster >> generated code, you should use GCC with -O2/-O3 and you need >> 20%-40% (150%-200% if you use GCC LTO) more time for compilation. I >> believe that LLVM code performance is far away from GCC because >> it is sufficiently easy to get first percents of code improvement, it >> becomes much harder to get subsequent percents, and IMHO starting with >> some point of the development the relation of the code improvement to >> the spent efforts might become exponential. So there is no magic -- >> GCC has a better performance because much more efforts of experienced >> compiler developers have been spent and are being spent for GCC >> development than for LLVM. >> >> The above said about compilation speed is true when GCC front-end is >> used for LLVM. LLVM has another C-language family front-end called >> CLANG which can speed up compilation in optimization mode >> (-O2/-O3) upto 20%-25%. So even as LLVM optimizations >> are not faster than GCC optimizations, CLANG front-end is really >> faster than GCC-frontend. I think GCC community should pay more attention >> to this fact. Fortunately, a few new GCC projects address to this problem >> and I hope this problem will be solved or alleviated. >> >> This year I used -Ofast -flto -fwhole-program instead of >> -O3 for GCC and -O3 -ffast-math for LLVM for comparison of peak >> performance. I could improve GCC performance even more by using >> other GCC possibilities (like support of AVX insns, Graphite optimizations >> and even some experimental stuff like LIPO) but I wanted to give LLVM >> some chances too. Probably an experienced user in LLVM could improve >> LLVM performance too. So I think it is a fair comparison. >>