search for: hardware_concurrency

...://reviews.llvm.org/D38481 introduced the usage of CPU_COUNT defined in glibc sched.h header. I failed to find this symbol in sched.h of glibc version 2.5-24, so compilation just fails. /home/dolphin/merge-from-upstream-area/ws/pristine/lib/Support/Threading.cpp: In function 'unsigned int llvm::hardware_concurrency()': /home/dolphin/merge-from-upstream-area/ws/pristine/lib/Support/Threading.cpp:80:26: error: 'CPU_COUNT' was not declared in this scope return CPU_COUNT(&Set); ^ It is buildable with newest version of glibc. I tried to find a requirements for glibc...

...build llvm-tblgen, you’ll know quite quickly :) > > > Also, you should limit the number of parallel link jobs: cmake > -DLLVM_PARALLEL_LINK_JOBS=1 > And use ninja if you don’t already: cmake -GNinja > Yes and to add on - the ThinLTO backend by default will kick off std::thread::hardware_concurrency # of threads, which I'm finding is too much for machines with hyperthreading. If that ends up being an issue I can give you a workaround (I've been struggling to find a way that works on various OS and arches to compute the max number of physical cores to fix this in the source). Teresa...

...ttps://reviews.llvm.org/D38481 introduced the usage of CPU_COUNT defined in glibc sched.h header. I failed to find this symbol in sched.h of glibc version 2.5-24, so compilation just fails. /home/dolphin/merge-from-upstream-area/ws/pristine/lib/Support/Threading.cpp: In function ‘unsigned int llvm::hardware_concurrency()’: /home/dolphin/merge-from-upstream-area/ws/pristine/lib/Support/Threading.cpp:80:26: error: ‘CPU_COUNT’ was not declared in this scope return CPU_COUNT(&Set); ^ It is buildable with newest version of glibc. I tried to find a requirements for glibc version in L...

> Sounds like threading isn't beneficial much beyond the second CPU... > Maybe blindly creating one thread per core isn't the best plan... parallel.h is pretty simplistic at the moment. Currently it creates one per SMT. One per core and being lazy about it would probably be a good thing, but threading is already beneficial and improving parallel.h an welcome improvement. Cheers,

...is pretty simplistic at the moment. Currently it creates >> one per SMT. One per core and being lazy about it would probably be a >> good thing, but threading is already beneficial and improving >> parallel.h an welcome improvement. >> > > Instead of using std::thread::hardware_concurrency (which is one per > SMT), you may be interested in using the facility I added for setting > default ThinLTO backend parallelism so that one per physical core is > created, llvm::heavyweight_hardware_concurrency() (see D25585 and > r284390). The name is meant to indicate that this is th...

...the moment. Currently it creates >>> one per SMT. One per core and being lazy about it would probably be a >>> good thing, but threading is already beneficial and improving >>> parallel.h an welcome improvement. >>> >> >> Instead of using std::thread::hardware_concurrency (which is one per >> SMT), you may be interested in using the facility I added for setting >> default ThinLTO backend parallelism so that one per physical core is >> created, llvm::heavyweight_hardware_concurrency() (see D25585 and >> r284390). The name is meant to indicate...

...l.com> >> wrote: >> > >> > On Sat, Sep 17, 2016 at 2:07 AM, Teresa Johnson via llvm-dev >> > <llvm-dev at lists.llvm.org> wrote: >> > >> >> Yes and to add on - the ThinLTO backend by default will >> >> kick off std::thread::hardware_concurrency # of threads, which I'm >> finding is >> > >> > Is it just me or does that sound not very intuitive or at least a >> > little unexpected? >> > It's good that it uses the resources eagerly, but in terms of build >> systems this >> > is...

> On Sep 16, 2016, at 4:46 PM, Carsten Mattner <carstenmattner at gmail.com> wrote: > > On Sat, Sep 17, 2016 at 12:48 AM, Teresa Johnson <tejohnson at google.com <mailto:tejohnson at google.com>> wrote: >> >> On Fri, Sep 16, 2016 at 2:54 PM, Carsten Mattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> On Fri, Sep 16,

...> CPU_COUNT defined in glibc sched.h header. > > I failed to find this symbol in sched.h of glibc version 2.5-24, > so compilation just fails. > > /home/dolphin/merge-from-upstream-area/ws/pristine/lib/Support/Threading.cpp: > In function ‘unsigned int llvm::hardware_concurrency()’: > > /home/dolphin/merge-from-upstream-area/ws/pristine/lib/Support/Threading.cpp:80:26: > error: ‘CPU_COUNT’ was not declared in this scope > >      return CPU_COUNT(&Set); > >                           ^ > > It is buildable with newest version...

...for other cases. >> 4. When prepare-code-coverage-artifact.py invokes llvm-profdata for >> the profiles generated by "make check", it takes 50GB of memory to >> process about 1.5GB of profiles. Is it supposed to use that much? > > By default, llvm-profdata uses hardware_concurrency() to determine the > number of threads to use to merge profiles. You can change the default > by passing -j/--num-threads to llvm-profdata. I'm open to changing the > 'prep' script to use -j4 or something like that. > Oh, so it's using a couple gigabytes per thread m...

...CPU_COUNT defined in glibc sched.h header. >> >> I failed to find this symbol in sched.h of glibc version 2.5-24, so >> compilation just fails. >> >> /home/dolphin/merge-from-upstream-area/ws/pristine/lib/Support/Threading.cpp: >> In function ‘unsigned int llvm::hardware_concurrency()’: >> >> /home/dolphin/merge-from-upstream-area/ws/pristine/lib/Support/Threading.cpp:80:26: >> error: ‘CPU_COUNT’ was not declared in this scope >> >> return CPU_COUNT(&Set); >> >> ^ >> >> >> >> I...

I've started looking at the state of code coverage recently; we figured LLVM itself would be a good test to figure out how mature it is, so I gave it a shot. My experience: 1. You have to specify -DLLVM_USE_LINKER=gold (or maybe lld works; I didn't try). If you link with binutils ld, the program will generate broken profile information. Apparently, the linked binary is missing the