Displaying 20 results from an estimated 7000 matches similar to: "Building with LLVM_PARALLEL_XXX_JOBS"
2016 Feb 25
4
Building with LLVM_PARALLEL_XXX_JOBS
On Thu, Feb 25, 2016 at 7:37 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:
>
>> On Feb 24, 2016, at 9:55 PM, Sedat Dilek via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>
>> Hi,
>>
>> I switched from "configure and make" to "cmake" build-system and
>> wanted to speedup my build.
>>
>> In my build-script I
2016 Feb 25
0
Building with LLVM_PARALLEL_XXX_JOBS
> On Feb 24, 2016, at 9:55 PM, Sedat Dilek via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> Hi,
>
> I switched from "configure and make" to "cmake" build-system and
> wanted to speedup my build.
>
> In my build-script I use...
>
> CMAKE_JOBS="1"
> ##CMAKE_JOBS=$(($(getconf _NPROCESSORS_ONLN)+1))
>
2016 Feb 25
0
Building with LLVM_PARALLEL_XXX_JOBS
On linux (not Windows) I doubt using Ninja vs make will make drastic
differences.. (Others with actual numbers please chime in to correct
me)
/*
I think the difference could be more beneficial if you're doing
incremental builds, but I don't think that is what you're doing..
*/
On Thu, Feb 25, 2016 at 1:51 PM, Sedat Dilek via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> On
2016 Feb 25
1
Building with LLVM_PARALLEL_XXX_JOBS
On Thu, Feb 25, 2016 at 7:55 AM, C Bergström <cbergstrom at pathscale.com> wrote:
> On linux (not Windows) I doubt using Ninja vs make will make drastic
> differences.. (Others with actual numbers please chime in to correct
> me)
>
> /*
> I think the difference could be more beneficial if you're doing
> incremental builds, but I don't think that is what
2016 Feb 25
1
Building with LLVM_PARALLEL_XXX_JOBS
> Which combination of cmake/ninja versions are you using (latest are
> v3.4.3 and v1.6.0)?
>
With this combination I could reduce build-time down from approx. 3h
down to 01h20m.
$ egrep -i 'jobs|ninja' llvm-build/CMakeCache.txt
//Program used to build from build.ninja files.
CMAKE_MAKE_PROGRAM:FILEPATH=/opt/cmake/bin/ninja
//Define the maximum number of concurrent compilation
2016 Mar 01
2
Building with LLVM_PARALLEL_XXX_JOBS
> On Mar 1, 2016, at 9:57 AM, Chris Bieneman <cbieneman at apple.com> wrote:
>
> There are a few notes I'd like to add to this thread.
>
> (1) we have a number of places throughout out CMake build where we use features from newer CMakes gated by version checks. Most of these features are performance or usability related. None of them are correctness. Using the latest
2016 Mar 01
2
Building with LLVM_PARALLEL_XXX_JOBS
For faster builds and rebuilds you should definitely read:
https://blogs.s-osg.org/an-introduction-to-accelerating-your-build-with-clang/
https://blogs.s-osg.org/a-conclusion-to-accelerating-your-build-with-clang/
Hope this helps!
On Tue, Mar 1, 2016 at 9:17 PM, ChrisBieneman via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
>
> > On Mar 1, 2016, at 10:01 AM, Mehdi Amini
2016 Mar 02
2
Building with LLVM_PARALLEL_XXX_JOBS
Hey Chris,
Sedat was asking for a way to "to speedup my build" and those blog posts
were really helpful to me.
Anyway LLVM_DISTRIBUTION_COMPONENTS sounds very cool, hope you will push
your code soon!
On Tue, Mar 1, 2016 at 11:32 PM, Chris Bieneman <cbieneman at apple.com> wrote:
> Fabio, the work I was mentioning here is an extension beyond those blog
> posts.
>
>
2016 Mar 03
2
Building with LLVM_PARALLEL_XXX_JOBS
> On Mar 2, 2016, at 4:22 PM, Sedat Dilek <sedat.dilek at gmail.com> wrote:
>
> I got some more inspirations on how to speedup my build and integrated
> the URLs into my scripts (attached).
>
> For example to use GOLD as linker or to use '-O3' OptLevel maybe in
> combination with LTO and PGO (using '-O3 -flto -fprofile-use').
LTO *will* slow down
2016 Mar 03
3
Building with LLVM_PARALLEL_XXX_JOBS
I had only a quick view on the blog-texts.
It might be that a CLANG generated with LTO/PGO speeds up the build.
Can you confirm this?
Can you confirm binutils-gold speed up the build?
Has LLVM an own linker?
Can be used? Speedup the build?
Yesterday night I loooked through available CMAKE/LLVM variables...
### GOLD
# CMAKE_LINKER:FILEPATH=/usr/bin/ld
#
2016 Mar 12
4
Building with LLVM_PARALLEL_XXX_JOBS
On Fri, Mar 4, 2016 at 11:28 AM, Tilmann Scheller
<tilmann at osg.samsung.com> wrote:
> Hi Sedat,
>
> On 03/03/2016 08:09 AM, Sedat Dilek via llvm-dev wrote:
>>
>> It might be that a CLANG generated with LTO/PGO speeds up the build.
>> Can you confirm this?
>
> Yes, a Clang host compiler built with LTO or PGO is generally faster than an
> -O3 build.
>
2016 Mar 18
2
Building with LLVM_PARALLEL_XXX_JOBS
On Thu, Mar 17, 2016 at 11:45 AM, Sedat Dilek <sedat.dilek at gmail.com> wrote:
> On Thu, Mar 17, 2016 at 10:05 AM, Sedat Dilek <sedat.dilek at gmail.com> wrote:
>> On Mon, Mar 14, 2016 at 5:30 PM, Chris Bieneman <cbieneman at apple.com> wrote:
>> [ brutal-snip ]
>> ...
>>> [ TODO#S: Before doing a 2nd build (and in a 3rd run using more
>>>
2016 Feb 26
0
[LLVM v3.8.0rc3] cmake-2.8.12: Statistics gcc-4.9 VS. clang-3.8
[ Please CC me I am not subscribed to this ML ]
Original posting from [1]...
<QUOTE>
On Thu, Feb 25, 2016 at 05:13:05PM +0100, Sedat Dilek via llvm-dev wrote:
> Build-time increased approx. 1h from 2 to 3 hours when using CMAKE
> instead of CONFIGURE/MAKE (logs deleted for LLVM v3.8.0rc2).
> Building always done with one single parallel-compile-jobs.
> When using CMAKE
2016 Mar 17
2
Building with LLVM_PARALLEL_XXX_JOBS
On Mon, Mar 14, 2016 at 5:30 PM, Chris Bieneman <cbieneman at apple.com> wrote:
[ brutal-snip ]
...
> [ TODO#S: Before doing a 2nd build (and in a 3rd run using more
> optimized binaries) ]
>
> How do I anable LTO via CMAKE?
>
>
> LLVM_ENALBLE_LTO=On
>
[ v4 of my build-script attached ]
Hi Chris,
thanks for the response!
That seems to work (see below).
$ cd
2016 Sep 20
4
(Thin)LTO llvm build
The configuration we’re mentioning is a 2-stage bootstrap: You need first to build without LTO your own clang, and then use it for the LTO build.
—
Mehid
> On Sep 20, 2016, at 10:17 AM, Michael Kruse <llvmdev at meinersbur.de> wrote:
>
> I am the author of Polly's/ISL's platform tests and could reproduce
> the problem on my system with this error message:
>
>
2012 Oct 12
0
[LLVMdev] cmake+ninja build error for compiler-rt sources
I use latest cmake+ninja which are built from latest sources.
=================================
> cmake --version
cmake version 2.8.9.20121011-g2876
=================================
--
mahesha
On Fri, Oct 12, 2012 at 7:35 PM, Mahesha HS <mahesha.llvm at gmail.com> wrote:
> Hi All,
>
> I am first time trying build CLANG+LLVM using cmake+ninja build
> system. I updated all
2012 Oct 13
0
[LLVMdev] [cfe-dev] cmake+ninja build error for compiler-rt sources
On Fri, Oct 12, 2012 at 6:14 PM, Chandler Carruth <chandlerc at google.com> wrote:
> I'm seeing this too. CC'ing the author ubsan stuff.
>
> Richard, I know you were OK with only supporting Clang-bootstraps, but I
> don't think that's terribly viable here.
Just out of curiosity - why isn't that viable? I'd sort of hope to
treat optional sanitizer runtimes
2012 Oct 13
2
[LLVMdev] [cfe-dev] cmake+ninja build error for compiler-rt sources
On Sat, Oct 13, 2012 at 1:09 AM, David Blaikie <dblaikie at gmail.com> wrote:
> On Fri, Oct 12, 2012 at 6:14 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
> > I'm seeing this too. CC'ing the author ubsan stuff.
> >
> > Richard, I know you were OK with only supporting Clang-bootstraps, but I
> > don't think that's terribly viable
2012 Oct 12
2
[LLVMdev] cmake+ninja build error for compiler-rt sources
Hi All,
I am first time trying build CLANG+LLVM using cmake+ninja build
system. I updated all my CLANG+LLVM sources to current trunk, and I
successfully built it using classic *make* build system. But, trying
to build the same with cmake+ninja build system resulting in following
build failures for compiler-rt sources.
Am I missing something basics here?
====================
cmake command used:
2012 Oct 13
2
[LLVMdev] [cfe-dev] cmake+ninja build error for compiler-rt sources
I'm seeing this too. CC'ing the author ubsan stuff.
Richard, I know you were OK with only supporting Clang-bootstraps, but I
don't think that's terribly viable here. We should be able to build ubsan's
runtime with standards conforming code unless there is some fairly extreme
reason not to...
On Fri, Oct 12, 2012 at 7:19 AM, Mahesha HS <mahesha.llvm at gmail.com> wrote: