Displaying 20 results from an estimated 1000 matches similar to: "PGO question"
2016 Mar 22
3
Instrumented BB in PGO
Hello,
I have a question regarding PGO instrumented BBs (I use IR-level
instrumentation).
It seems that instrumented BBs do not match between the two compilations
for profile-gen and profile-use for some cases. Here is an example from
SPECcpu 2006 lbm (a simple case consisting of just two modules).
In the first compilation, we have 5 instrumentation points for the main
function as follows:
$
2016 Mar 07
3
Profile-based inlining status
Hello,
I'm learning how LLVM performs PGO (profile-guided optimizations) by using
the instrumentation-based profile build (-fprofile-instr-generate and
-fprofile-instr-use).
However, I found there is no difference in inlining behaviors between with
and without PGO for a few spec benchmarks by checking the emit optimization
reports (-Rpass=inline -Rpass-missed=inline -Rpass-analysis=inline).
2015 Jun 17
4
[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
2018 Jul 31
2
LLJVM make error
Hi fellow devs,
I was looking for converting LLVM IR to JavaBytecode by using lljvm
project of https://github.com/davidar/lljvm
They don't seem to compile, once i run *make* in the root directory it give
me the error :
cd include && make all
make[1]: Entering directory `/home/rtiwari1/llvm_new/lljvm/include'
make[1]: Nothing to be done for `all'.
make[1]: Leaving
2015 May 22
2
[LLVMdev] GCC compatibility code coverage issue .
Hi Justin ,
Thank you for the confirmation and we would like to know that ,going
forward the clang has the support the gcc gcov format or use the
-fprofile-instr-generate -fcoverage-mapping and get ride of gcov
format .
We are planing to customize the clang code coverage for embedded world
,before we start tweaking the gcov / -fprofile-instr-generate
code-base ,we would like to take feedback
2015 May 27
0
[LLVMdev] GCC compatibility code coverage issue .
Umesh Kalappa <umesh.kalappa0 at gmail.com> writes:
> Hi Justin ,
>
> Thank you for the confirmation and we would like to know that ,going
> forward the clang has the support the gcc gcov format or use the
> -fprofile-instr-generate -fcoverage-mapping and get ride of gcov
> format .
Going forward, the -fprofile-instr-generate -fcoverage-mapping (which
I'll refer to as
2015 Jun 17
2
[LLVMdev] RFC - Stop ignoring -fprofile-generate and -fprofile-use
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 simpler.
>From https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html:
2018 Aug 01
2
LLJVM make error
That source file was removed from LLVM in r232397 on March 16, 2015.
It looks like lljvm hasn't been updated in a long time. LLVM's C++ APIs are not stable, so there is no expectation that a project built against LLVM's C++ API in 2015 would build or reasonably function against LLVM trunk.
The project probably works against LLVM 3.6.2 which was (I believe) the last LLVM release to
2020 Jan 14
2
Incorrect code generation when using -fprofile-generate on code which contains exception handling (Windows target)
I think the simplest, most complete, short term fix, would be to call
llvm::colorEHFunclets, and to have the relevant instrumentation passes
apply the appropriate funclet bundle when inserting function calls. It's
not elegant because it means every simple instrumentation pass that inserts
regular function calls (ASan, TSan, MSan, instrprof, etc) needs to be
funclet-aware. But, it will work,
2020 Jan 13
2
Incorrect code generation when using -fprofile-generate on code which contains exception handling (Windows target)
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
2015 Apr 09
2
[LLVMdev] code coverage instrumentation
Hi
Not sure if this is a clang or llvm related question so I'm sending to both mailing lists.
Anyways, I have few questions regarding size and execution time of instrumented code:
We are trying to run code coverage on memory limited hardware and investigating both (generating gcov output using -coverage and the llvm's own way using -fprofile-instr-generate -fcoverage-mapping clang flags)
2013 Jun 17
2
[LLVMdev] vmkit java annotations
Hello everyone,
I am able to work very well with annotations in C/C++, by using
__attribute__((annotate("MYANNOTATION"))) static int a; . Inside the LLVM
bytecode I have @llvm.global.annotations and @llvm.var.annotation.
However, I was trying to test annotations also in Java, with VMKit. These
are the commands that I run:
javac -Xlint -g -O Main.java
../Release+Asserts/bin/vmjc Main
2013 Jun 17
2
[LLVMdev] vmkit java annotations
Hello Harris,
Thank you for your answer. So it is there a way of annotating variables in
Java Code, so I can see them into LLVM bytecode?
Thank you !
On Mon, Jun 17, 2013 at 3:54 PM, Harris BAKIRAS <h.bakiras at gmail.com> wrote:
> Hello Alexandru,
>
> No you did nothing wrong.
>
> We are using our own data structure to describe annotations in J3. So it
> is normal
2013 Jun 17
0
[LLVMdev] vmkit java annotations
Hello Alexandru,
No you did nothing wrong.
We are using our own data structure to describe annotations in J3. So it
is normal that you can not see your Java annotations inside the LLVM
bytecode produced.
If I remember well, our implementation of annotations do not rely on
LLVM annotations.
Regards,
Harris Bakiras
On 06/17/2013 02:19 PM, Alexandru Ionut Diaconescu wrote:
> Hello
2013 Jun 17
0
[LLVMdev] vmkit java annotations
What classpath implementation are you using ? GNUClasspath or OpenJDK ?
Harris Bakiras
On 06/17/2013 03:57 PM, Alexandru Ionut Diaconescu wrote:
> Hello Harris,
>
> Thank you for your answer. So it is there a way of annotating
> variables in Java Code, so I can see them into LLVM bytecode?
>
> Thank you !
>
>
> On Mon, Jun 17, 2013 at 3:54 PM, Harris BAKIRAS
2017 Jul 01
7
[RFC] Placing profile name data, and coverage data, outside of object files
Problem
-------
Instrumentation for PGO and frontend-based coverage places a large amount of
data in object files, even though the majority of this data is not needed at
run-time. All the data is needlessly duplicated while generating archives, and
again while linking. PGO name data is written out into raw profiles by
instrumented programs, slowing down the training and code coverage workflows.
2016 Mar 11
5
RFC: Pass to prune redundant profiling instrumentation
There have been a lot of responses. I'll try to summarize the thread and respond
to some of the questions/feedback.
Summary
=======
1. We should teach GlobalDCE to strip out instrumented functions which the
inliner cannot delete.
2. Sean suggests adding metadata to loads/stores of counters to convey that
they do not alias normal program data.
I'm not familiar with AA, but
2015 Aug 08
3
RFC: PGO Late instrumentation for LLVM
Instrumentation based Profile Guided Optimization (PGO) is a compiler
technique that leverages important program runtime information, such as
precise edge counts and frequent value information, to make frequently
executed code run faster. It's proven to be one of the most effective ways
to improve program performance.
An important design point of PGO is to decide where to place the
2017 Jul 01
4
[RFC] Placing profile name data, and coverage data, outside of object files
On Fri, Jun 30, 2017 at 5:54 PM, via llvm-dev <llvm-dev at lists.llvm.org>
wrote:
> Problem
> -------
>
> Instrumentation for PGO and frontend-based coverage places a large amount
> of
> data in object files, even though the majority of this data is not needed
> at
> run-time. All the data is needlessly duplicated while generating archives,
> and
> again while
2016 Mar 11
8
RFC: Pass to prune redundant profiling instrumentation
Hi,
I'd like to add a new pass to LLVM which removes redundant profile counter
updates. The goal is to speed up code coverage testing and profile generation
for PGO.
I'm sending this email out to describe my approach, share some early results,
and gather feedback.
Problem Overview
================
A profile counter is redundant if it's incremented in exactly the same basic
blocks