similar to: PGO, zlib and 'default.profraw'

Can we improve the error message here? We should be able to check zlib::isAvailable and give an error like "profile uses zlib compression but the profile reader was built without zlib support" or so in this case. Xinliang David Li via llvm-dev <llvm-dev at lists.llvm.org> writes: > The __llvm_prf_names section is compressed but your llvm-profdata tool is > probably not built

set LLVM_ENABLE_ZLIB=ON with cmake invocation. zlib should be installed and zlib.h header file needs to be in the header search path. Is your llvm-profdata tool built together with clang? David On Tue, Jul 18, 2017 at 1:04 PM, Martin J. O'Riordan via llvm-dev < llvm-dev at lists.llvm.org> wrote: > How can I build the profile reader with ZLIB support enabled? I configure > and

Hi David, When I use CMake to configure, ‘zlib’ and its header are detected - I build on CentOS 6.5 or CentOS 7. Since I run CMake from the command-line, I tried added ‘-DLLVM_ENABLE_ZLIB=0’ and ‘-DLLVM_ENABLE_ZLIB=1’ (using ‘-DLLVM_ENABLE_ZLIB=ON’ does not seem to work). Both ‘clang’ and ‘llvm-profdata’ (and all other tools and utilities) are configured and built together, in any event,

Yes, that was it! Now that I took a closer look, the guide also states that I should use the stage2 build. Silly me. Thanks! On Tue, 3 Sep 2019 at 19:31, David Blaikie <dblaikie at gmail.com> wrote: > I /guess/ you actually want /path/to/release_build/llvm-profdata because > the profiles are generated from binaries compiled with the release build, > so it's the release build

Hi! I'm trying to build a fast Clang for myself to use for debug builds on Clang itself, but I've been struggling for a very long time on it. Could you please help? I've been following this guide: https://llvm.org/docs/HowToBuildWithPGO.html I've quickly learned that its outdated, because the script it talks about doesn't work with the monorepo layout at all, but in any

On Fri, Jan 15, 2016 at 11:41 AM, Xinliang David Li <davidxl at google.com> wrote: > Tagging profile data with such information is generally useful. My > thoughts are > > 1) such information is probably not needed to be stored in raw format > profile data -- so no runtime changes are needed -- only llvm-profdata > and indexed format need to be enhanced to support this.

Not 100% if this is an LLVM question or a CLang question, though I expect LLVM. On Linux, if I pass '-fsave-optimization-record' to 'clang', then it produces a '*.opt.yaml' file. However, the same thing run on Windows using 'clang' built with VS2015 silently ignores this option. Is this a bug or is it intentional? And if it is intentional, how can I configure

Hi all, I'd liked to get your thoughts on possibly adding a generic key-value store to the profile data formats for 'metadata'. Some potential uses cases: *I. Profile Features* The most basic use could be as a central repository for internal bits of housekeeping information about the profile data. For example, to differentiate between FE and IR instrumentation:

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: $

Hi LLVM-Devs, The LLVM 'cl::opt' templates are really useful, and provide a lot of flexibility. But I don't see any support for ranged options. What I would like is to have an option which is an integer type, and to restrict the set of values provided to a simple upper and lower bound, for example between 10 and 2000. Is there a way of expressing this with the 'cl::opt'

Hi LLVM-Devs, I am considering switching to using 'llvm-lld' instead of Gnu 'ld' in a future revision of our out-of-tree target, and I am wondering is there a getting started guide for how to go about extending 'llvm-lld' to support an additional target. Thanks, MartinO -------------------------------------------------------------- Intel Research and Development

Thanks for testing out LLVM PGO and evaluated the performance. We are currently still more focused on infrastructure improvement which is the foundation for performance improvement. We are making great progress in this direction, but there are still some key missing pieces such as profile data in inliner etc. We are working on that. Once those are done, more focus will be on making more passes

With LLVM v5.0, I found failures in some of the 'gcc.c-torture/execute' tests due to a change in the optimisation where undefined behaviour is involved. The tests that fail are the '20040409-[123].c' tests. The underlying failure is due to the optimisation of the following: int test2(int x) { return x + INT_MIN; } from using an ADD instruction to using an OR instruction.

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

Hi, The insertion of DBG_VALUE instructions for spills does not seem to be handling insert locations inside bundles well. If the spill instruction is part of a bundle, the new DBG_VALUE is inserted after it, but does not have the bundling flags set. This essentially means that if we start with a set of bundled instructions: MI1 [BundledSucc=true, BundledPred=false] MI2 [BundledSucc=false,

I think that this proposal would be very useful, and I will describe our experiences of trying to do this for our embedded bare-metal target. Recently we implemented support for just the '-fprofile-instr-generate' option and the 'compiler-rt/lib/profile' sources, and added the following to our LD scripts: /* Append the LLVM profiling sections */ . = ALIGN(4);

Hello, I am using domain event notifications from libvirt-event API in my application and it seems to work fine, except for 'suspend' and 'resume' events where I keep receiving duplicated notifications. Similarly, the example provided with libvirt (in examples/object-events/event-test) also produces twice as much notifications for 'suspend' and 'resume' than for

Yes, the hairy-edges of undefined behaviour - UB is UB. It does mean that given: __attribute__((noinline)) int foo(int a, int b) { return a + b; } int bar1(int x) { return foo(x, INT_MIN); } int bar2(int x) { return x + INT_MIN; } 'bar1' and 'bar2' have different outcomes. However, I think that the new optimisation is neat and valid and I am not suggesting that it should

I am trying to support an experimental DSL that uses non-C identifiers, but I want to write the implementation of the runtime support libraries for this DSL in C. The compiler is built using the LLVM v5.0.0 release branch. To do this I thought I could simply write: int foo() { return 42; } // The C implementation asm(".alias nonCname foo"); // Make the non-C name be a synonym for

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