similar to: [LLVMdev] RFC - Stop ignoring -fprofile-generate and -fprofile-use

On 2015 Jun 17, at 13:53, Diego Novillo <dnovillo at google.com> wrote: > The flags -fprofile-generate and -fprofile-use are currently ignored > for GCC compatibility. I would like to enable them and give them > similar semantics to GCC. These flags are baked pretty deeply into > our build environment, so supporting them at the driver level will > make our lives a lot

Hi! I am trying to get a combined coverage report from multiple executables. Looking at earlier discussions [1, 2], it looks like this is supposed to work. I am having some difficulty getting this to work as I would expect it to work, however. Following is a simple case to explain: ////////// shared.h #include <string> void Print1(const std::string& msg); void Print2(const

Hi Sadrul, > On Mar 8, 2018, at 7:40 PM, Sadrul Chowdhury via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi! I am trying to get a combined coverage report from multiple > executables. Looking at earlier discussions [1, 2], it looks like this > is supposed to work. I am having some difficulty getting this to work > as I would expect it to work, however. Following is

Hi Diego, thanks for clarifying the difference between the two formats. I have noticed the new note in the "Sample Profile Format" section of the Clang guide clarifying that it is different from the coverage format. So, my further question is... Am I right in understanding that both formats can be used for PGO purposes then? I have tried the following, as in the Clang user guide: $

Hello, We have a user that wants to get the code coverage report for his library without turning on instrumentation for the library clients or change how they are built (only the library is instrumented). It seems like the inline member functions defined in headers are not instrumented in this case because the clients are not instrumented. The library itself does not have a copy of the inline

The problem is that ThinLTO is not dropping the non-prevailing definitions, and they end up being emitted into the object file for b.o. $ ../ra/bin/llvm-dis -o - b.o0.0.preopt.bc | grep __llvm_prof $__llvm_profile_raw_version = comdat any $__llvm_profile_filename = comdat any @__llvm_profile_raw_version = constant i64 72057594037927940, comdat @__llvm_profile_filename = constant [19 x i8]

Adding Peter to comment on the linker resolution issue. >From adding save-temps, it looks like lld and gold are giving different resolutions to the symbols, which is presumably creating this issue: (first file is with lld and second is with gold) $ diff a.out.resolution.txt gold/ 4c4 < -r=a.o,__llvm_profile_raw_version,plx --- > -r=a.o,__llvm_profile_raw_version,l 8,9c8,9 <

Thanks Peter, your patch does fix the reproducer. I filed https://bugs.llvm.org/show_bug.cgi?id=37422 to track this bug. I have no clue on how to resolve the tests - whether further cleanup is required in the code or in the tests. But if Teresa or you cannot get to it, I can, with some help, take a crack at fixing the tests. On Wed, May 9, 2018 at 11:26 AM Peter Collingbourne <peter at

Hi all! It seems I came across on issue with coverage mapping (http://www.llvm.org/docs/CoverageMappingFormat.html) check on: llvm revision: r228136 clang Last Changed Rev: 228121 build: Debug+Asserts OS: ubuntu 14.04 Here is simple snippets test1.c: NOT OK ================== #include <stdio.h> static int foo() { return 42; } int main() { return 0; } ================== cp src/test1.c

The duplicate symbol errors are for __llvm_profile_filename and __llvm_profile_raw_version. IIUC, these are supposed to be weak symbols but Thin LTO seems to break this in some way. This does't happen with gold or no LTO or full LTO. $ cat > a.c extern int foo(); int main() { return foo(); } $ cat > b.c int foo() { return 0; } $ clang a.c -fprofile-generate -flto=thin -c $ clang

Hi Pirama, I can't reproduce with either lld or gold, using a compiler built from head. What version is your clang? Thanks, Teresa On Tue, May 8, 2018 at 7:50 PM Pirama Arumuga Nainar via llvm-dev < llvm-dev at lists.llvm.org> wrote: > The duplicate symbol errors are for __llvm_profile_filename and __llvm_profile_raw_version. > IIUC, these are supposed to be weak symbols but

On Wed, May 9, 2018 at 6:43 AM Teresa Johnson <tejohnson at google.com> wrote: > Hi Pirama, > > I can't reproduce with either lld or gold, using a compiler built from > head. What version is your clang? > (and your lld) > > Thanks, > Teresa > > On Tue, May 8, 2018 at 7:50 PM Pirama Arumuga Nainar via llvm-dev < > llvm-dev at lists.llvm.org>

Hi Teresa, Thanks for looking into this. I hadn't initially tried ToT, but it reproduces in ToT as well when I tried. $ ./clang --version clang version 7.0.0 (trunk 331879) (llvm/trunk 331888) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /ssd2/pirama/llvm-upstream/llvm-release/bin/. $ ./ld.lld --version LLD 7.0.0 (https://git.llvm.org/git/lld.git

On Thu, Apr 17, 2014 at 6:10 PM, Yaron Keren <yaron.keren at gmail.com> wrote: > If accuracy is not critical, incrementing the counters without any guards > might be good enough. > No. Contention on the counters leads to 5x-10x slowdown. This is never good enough. --kcc Hot areas will still be hot and cold areas will not be affected. > > Yaron > > > >

Hi, all Recently I'm trying to use LLVM PGO and autoFDO. However I have some problems in the process. LLVM source code is updated on April 9th. Operating system is SUSE x86_64 1. Problems in instrumentation based PGO: clang -O2 -fprofile-instr-generate test.c -o a.out ./a.out (then default.profraw is generated) clang -O2 -fprofile-instr-use=default.profraw test.c -o a.out

LLD revision is r331862. To add, I had initially tried it on r328903, which also reproduced the issue. On Wed, May 9, 2018 at 9:26 AM Pirama Arumuga Nainar <pirama at google.com> wrote: > Hi Teresa, > > Thanks for looking into this. I hadn't initially tried ToT, but it > reproduces in ToT as well when I tried. > > $ ./clang --version > > clang version 7.0.0

Sorry, operator error. I can reproduce now. Interestingly, this does not reproduce using gold, and they utilize the same underlying LTO API. Let me dig a little using save-temps and see where they diverge. Teresa On Wed, May 9, 2018 at 9:28 AM Pirama Arumuga Nainar <pirama at google.com> wrote: > LLD revision is r331862. To add, I had initially tried it on r328903, > which also

> On Jun 2, 2016, at 5:30 PM, Sean Silva <chisophugis at gmail.com> wrote: > > This also means that if the consensus is that -fprofile-instr-generate should really change its meaning to mean IRPGO, I’m open to having this internal patch on our side. > > Yeah, it sounds like someone is going to have to keep a "private patch" to change the default. At that point

The PGO was my first guess but I can get a lot of information. At first, I follow the explanation at http://clang.llvm.org/docs/UsersManual.html#profiling-with-instrumentation but instead of llvm-profdata merge, I used llvm-profdata show *.profraw. Sadly, the information I get is the total number of function, the maximum function count and the maximum internal block count. Do you know if you

I think this is the same underlying issue as https://bugs.llvm.org/show_bug.cgi?id=40320. CCing Reid, who's had a bunch of thoughts on this in the past. On 1/11/20, 10:25 AM, "llvm-dev on behalf of Chrulski, Christopher M via llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org> wrote: Hi, I've run into a bug with the LLVM