similar to: llvm and clang are getting slower

On Tue, Mar 8, 2016 at 10:42 AM, Richard Smith via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Tue, Mar 8, 2016 at 8:13 AM, Rafael Espíndola > <llvm-dev at lists.llvm.org> wrote: > > I have just benchmarked building trunk llvm and clang in Debug, > > Release and LTO modes (see the attached scrip for the cmake lines). > > > > The compilers used were

On Tue, Mar 8, 2016 at 2:25 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Mar 8, 2016, at 1:09 PM, Sean Silva via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > On Tue, Mar 8, 2016 at 10:42 AM, Richard Smith via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On Tue, Mar 8, 2016 at 8:13 AM, Rafael Espíndola >>

I have noticed that LLVM doesn't seem to "like" large functions, as a general rule. Admittedly, my experience is similar with gcc, so I'm not sure it's something that can be easily fixed. And I'm probably sounding like a broken record, because I have said this before. My experience is that the time it takes to compile something is growing above linear with size of

----- Original Message ----- > From: "Mehdi Amini via cfe-dev" <cfe-dev at lists.llvm.org> > To: "Rafael Espíndola" <rafael.espindola at gmail.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "cfe-dev" <cfe-dev at lists.llvm.org> > Sent: Tuesday, March 8, 2016 11:40:47 AM > Subject: Re: [cfe-dev] [llvm-dev] llvm and

First of all, sorry for the long mail. Inspired by the excellent analysis Rui did for lld, I decided to do the same for llvm. I'm personally very interested in build-time for LTO configuration, with particular attention to the time spent in the optimizer. Rafael did something similar back in March, so this can be considered as an update. This tries to include a more accurate high-level

> On Dec 17, 2016, at 1:35 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > First of all, sorry for the long mail. > Inspired by the excellent analysis Rui did for lld, I decided to do > the same for llvm. > I'm personally very interested in build-time for LTO configuration, > with particular attention to the time spent in the optimizer. >

> On Dec 17, 2016, at 1:35 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > First of all, sorry for the long mail. > Inspired by the excellent analysis Rui did for lld, I decided to do > the same for llvm. > I'm personally very interested in build-time for LTO configuration, > with particular attention to the time spent in the optimizer. >

On Fri, Sep 16, 2016 at 10:54 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > Can you look for the specific errors in the CMake log and error files? > > CMake is very good at not presenting the real issue… > Here it is trying to build very simple programs to check features > availability. Like: > > #include <strings.h> > int main() { ffs(0); return 0;

On Sat, Dec 17, 2016 at 6:39 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> On Dec 17, 2016, at 1:35 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> First of all, sorry for the long mail. >> Inspired by the excellent analysis Rui did for lld, I decided to do >> the same for llvm. >> I'm personally very

Hi all, Can anyone give me advice about an appropriate way for extracting number of functions from module recursively (starting from entry point). Actually it may be more than one entry point so all dependent functions and global values must be extracted. I've tried llvm-extract tool but it can't do work recursively. Maybe it would be good to write some Call Graph pass or something. Any

On 10/27/16 11:18 AM, Aliaksei Zasenka via llvm-dev wrote: > Hi all, > Can anyone give me advice about an appropriate way for extracting > number of functions from module recursively (starting from entry > point). Actually it may be more than one entry point so all dependent > functions and global values must be extracted. > > I've tried llvm-extract tool but it

In the linked bug, the issue is that symbols defined in multiple places (LTO and non-LTO) are provided by the linker plugin (which in GCC's case marks the symbols as private). The error appears to be a difference in which symbol gold or ld picks as canonical. I don't think it's the same as the issue you're seeing (unless you're mixing LTO and non-LTO files). I'd guess

Hi all, I've been playing around with LLVM and LTO trying to compile some open-source projects. Prior to the 3.8 release I had been using r250630 (if I remember correctly) and I was able to successfully build GamePlay (https://github.com/gameplay3d/GamePlay). Sadly, since upgrading to 3.8 I am getting weird link-time-errors (error: undefined reference to 'XYZ::~XYZ'). It appears

How big is your project? LTO eats RAM even faster than chrome. For example linking clang with LTO could take 16GB of ram. Have you tried using LTO on your project on that machine, or is it your first time? Piotr On Sat, Jul 23, 2016 at 2:42 AM, Sedat Dilek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Jul 21, 2016 at 12:01 PM, Sedat Dilek <sedat.dilek at

We formally support our toolchain only on Windows 7 onward, so it's okay with us. (Please make sure this goes in the release notes when you start doing something not supported in XP and/or Vista.) --paulr From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Jim Rowan Sent: Friday, October 31, 2014 1:05 PM To: Reid Kleckner Cc: LLVM Developers Mailing List

On 12/17/2016 01:35 PM, Davide Italiano via llvm-dev wrote: > First of all, sorry for the long mail. > Inspired by the excellent analysis Rui did for lld, I decided to do > the same for llvm. > I'm personally very interested in build-time for LTO configuration, > with particular attention to the time spent in the optimizer. > Rafael did something similar back in March, so

Hi, this is about kicking-off regular compile-time tracking for LLVM and CLANG on the green dragon: http://lab.llvm.org:8080/green/view/Compile%20Time/ <http://lab.llvm.org:8080/green/view/Compile%20Time/>. The goal is to stay on top of compile-time issues immediately when they occur so they can be assessed rather than creeping in unnoticed. The methodology is simple: form a CTMark suite

Hi, In my version of R, the stats package splinefun code for fitting a Fritsch and Carlson monotonic spline does not appear to guarantee a monotonic result. If two adjoining sections both have over/undershoot the way the resulting adjustment of alpha and beta is performed can give modified values which still do not satisfy the required constraints. I do not think this is due to finite precision

Hi Teresa, Impressive results, indeed! (But no less is expected from an Itanium alumni... ;-)) One question, if you don't mind. In the blog post you wrote: "In a few cases ThinLTO even outperforms full LTO, most likely because the higher scalability of ThinLTO allows using a more aggressive backend optimization pipeline (similar to that of a non-LTO build)." Is it due to

Hello, I'm enabling clang LTO to improve code size of Uefi standard (http://www.uefi.org/) firmware (https://github.com/tianocore/edk2), which is mostly C code. My project is in https://github.com/shijunjing/edk2 branch llvm : https://github.com/shijunjing/edk2/tree/llvm. I find my most firmware modules work well after enable LTO, but some X64 modules will not run (e.g. hang with CPU