similar to: [LLVM v3.8.0rc3] cmake-2.8.12: Statistics gcc-4.9 VS. clang-3.8

Displaying 20 results from an estimated 200 matches similar to: "[LLVM v3.8.0rc3] cmake-2.8.12: Statistics gcc-4.9 VS. clang-3.8"

2016 Feb 25
1
[LLVM v3.8.0rc3] cmake-2.8.12: Statistics gcc-4.9 VS. clang-3.8
Hi, here some statistics when building LLVM v3.8.0rc3 with CMAKE and GCC v4.9.2 or CLANG v3.8.0rc3 here on my Ubuntu/precise AMD64 system. [ THE GOOD (disc-usage) ] Compiling with clang-3.8 produces smaller binaries VS. gcc-4.9 (approx. 250MiB smaller). Checking with 'wc -l' shows 1893 files in total for both install-dirs. $ cd /opt ; du -s -m llvm-toolchain-3.8.0rc3_* 609
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 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
2
Building with LLVM_PARALLEL_XXX_JOBS
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)) JOBS_CMAKE_OPTS="-DLLVM_PARALLEL_COMPILE_JOBS=$CMAKE_JOBS -DLLVM_PARALLEL_LINK_JOBS=$CMAKE_JOBS" [1] says in "LLVM-specific variables" section... ***
2016 Feb 25
2
[llvm-3.8-ec3] cmake-2.8.12 and gcc-4.6: Host compiler appears to require libatomic, but cannot find it.
Hi, when I switch to an unsupported GCC like v4.6.4 to build LLVM v3.8-rc3 with cmake I get the following: ... -- Looking for __atomic_fetch_add_4 in atomic -- Looking for __atomic_fetch_add_4 in atomic - not found CMake Error at cmake/modules/CheckAtomic.cmake:36 (message): Host compiler appears to require libatomic, but cannot find it. Call Stack (most recent call first):
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
2015 Feb 07
5
[LLVMdev] mesa-10.4.4: BROKEN TLS support in GLX with llvm-toolchain v3.6.0rc2
[ Please CC me I am not subscribed to mesa-dev and llvmdev MLs ] Hi, I already reported this when playing 1st time with my llvm-toolchain v3.6.0rc2 and mesa v10.3.7 [1]. The issue still remains in mesa v10.4.4. So, this is a field test to see if LLVM/Clang v3.6.0rc2 fits my needs. I see the following build-error... ... make[4]: Entering directory
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 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. >
2015 Feb 09
2
[LLVMdev] mesa-10.4.4: BROKEN TLS support in GLX with llvm-toolchain v3.6.0rc2
On Mon, Feb 9, 2015 at 6:44 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote: > Hi Sedat, > > On 07/02/15 22:42, Sedat Dilek wrote: >> [ Please CC me I am not subscribed to mesa-dev and llvmdev MLs ] >> >> Hi, >> >> I already reported this when playing 1st time with my llvm-toolchain >> v3.6.0rc2 and mesa v10.3.7 [1]. >> The issue still
2015 Feb 09
2
[LLVMdev] mesa-10.4.4: BROKEN TLS support in GLX with llvm-toolchain v3.6.0rc2
On 09/02/15 17:44, Emil Velikov wrote: > Hi Sedat, > > On 07/02/15 22:42, Sedat Dilek wrote: >> [ Please CC me I am not subscribed to mesa-dev and llvmdev MLs ] >> >> Hi, >> >> I already reported this when playing 1st time with my llvm-toolchain >> v3.6.0rc2 and mesa v10.3.7 [1]. >> The issue still remains in mesa v10.4.4. >> >> So,
2016 Feb 24
3
[3.8 Release] RC3 has been tagged
[ Original posting see [1] ] >From [1]: ... Added: llvm/tags/RELEASE_380/rc3/ (props changed) - copied from r261685, llvm/branches/release_38/ ... The LLVM Git repositories have no "rc3" tag in "release_38" branch (as an example llvm.git#release_38 see [2]). Who is responsible for that or maybe better... can you activate the responsible(s)? Helpful is to add
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 24
4
[3.8 Release] RC3 has been tagged
Git tags and SVN tags are completely different beasts (git tag is simply a "second name" attached to revision, while on svn the tag could be arbitrary different). There is no way to automate the process - in general svn tag might not correspond (by contents) to any other revision in the repository. The only way to somehow emulate svn tags on git is to create a separate branch on each