Displaying 20 results from an estimated 20000 matches similar to: "RFC: Reducing Instr PGO size overhead"
2015 Sep 05
5
RFC: Reducing Instr PGO size overhead
On Fri, Sep 4, 2015 at 9:11 PM, Sean Silva <chisophugis at gmail.com> wrote:
>
>
> On Fri, Sep 4, 2015 at 5:42 PM, Xinliang David Li <davidxl at google.com>
> wrote:
>>
>> On Fri, Sep 4, 2015 at 5:21 PM, Sean Silva <chisophugis at gmail.com> wrote:
>> >
>> >
>> > On Fri, Sep 4, 2015 at 3:57 PM, Xinliang David Li <davidxl at
2015 Sep 08
2
RFC: Reducing Instr PGO size overhead
>> >>
>> >> yes -- it is fixed length (8byte) blob which may include null byte in
>> >> the middle.
>> >
>> >
>> > For reference, MD5 sum is 16 bytes (128-bit):
>> > https://en.wikipedia.org/wiki/MD5
>>
>> yes, LLVM's MD5 hash only takes the lower 64bit.
>>
>>
>> >
>> >>
2015 Sep 04
2
RFC: Reducing Instr PGO size overhead
>
> I think it is reasonable to simply replace the key we currently use with
> MD5(key) for getting a size reduction. In practice for my use cases, I have
> not observed any of the issues you mentioned under "Large size of overhead
> can limit the usability of PGO greatly", but I can understand that some of
> these issues could become problems in Google's use case.
2015 Oct 09
2
RFC: Reducing Instr PGO size overhead
On Fri, Oct 9, 2015 at 3:58 PM, Sean Silva <chisophugis at gmail.com> wrote:
>
>
> On Wed, Oct 7, 2015 at 11:12 PM, Xinliang David Li <davidxl at google.com>
> wrote:
>>
>> There is no further response to this, so I will assume general
>> direction of solution-3 is acceptable ;)
> No response does not mean "LGTM".
>
What I meant is that
2015 Dec 09
2
RFC: Reducing Instr PGO size overhead
We are now very close to push the final stage of the PGO size
reduction task. Here is the updated plan going forward:
1) In this round, the format of the indexed profile data won't be unchanged.
2) there will be *no* changes in user interfaces to all profiling
related tools including llvm-profdata, llvm-cov -- the change will be
transparent in terms of PGO usability.
3) The implementation
2015 Oct 08
5
RFC: Reducing Instr PGO size overhead
There is no further response to this, so I will assume general
direction of solution-3 is acceptable ;)
Solution-3 can be further improved. Instead of using static symbol
table (with zero size __llvm_prf_nm symbols) to store function names
for profile display and coverage mapping, the function names can be
stored compressed in a non-allocatable section. The compression ratio
for function name
2015 Sep 05
4
RFC: Reducing Instr PGO size overhead
On Fri, Sep 4, 2015 at 5:21 PM, Sean Silva <chisophugis at gmail.com> wrote:
>
>
> On Fri, Sep 4, 2015 at 3:57 PM, Xinliang David Li <davidxl at google.com>
> wrote:
>>
>> >
>> > I think it is reasonable to simply replace the key we currently use with
>> > MD5(key) for getting a size reduction. In practice for my use cases, I
>> >
2015 Sep 05
3
RFC: Reducing Instr PGO size overhead
On Fri, Sep 4, 2015 at 11:03 PM, Sean Silva <chisophugis at gmail.com> wrote:
>
>
> On Fri, Sep 4, 2015 at 10:11 PM, Xinliang David Li <davidxl at google.com>
> wrote:
>>
>> On Fri, Sep 4, 2015 at 9:11 PM, Sean Silva <chisophugis at gmail.com> wrote:
>> >
>> >
>> > On Fri, Sep 4, 2015 at 5:42 PM, Xinliang David Li <davidxl at
2016 May 25
0
The state of IRPGO (3 remaining work items)
On Tue, May 24, 2016 at 3:41 PM, Vedant Kumar <vsk at apple.com> wrote:
>
> > On May 23, 2016, at 8:56 PM, Xinliang David Li <davidxl at google.com>
> wrote:
> >
> > On Mon, May 23, 2016 at 8:23 PM, Sean Silva <chisophugis at gmail.com>
> wrote:
> > Jake and I have been integrating IRPGO on PS4, and we've identified 3
> remaining work
2016 Jun 03
5
The state of IRPGO (3 remaining work items)
On Thu, Jun 2, 2016 at 5:30 PM, Sean Silva <chisophugis at gmail.com> wrote:
>
>
> On Thu, Jun 2, 2016 at 2:51 PM, Frédéric Riss <friss at apple.com> wrote:
>
>>
>> On Jun 2, 2016, at 12:10 AM, Sean Silva <chisophugis at gmail.com> wrote:
>>
>>
>>
>> On Wed, Jun 1, 2016 at 5:46 PM, Frédéric Riss <friss at apple.com> wrote:
2016 Jun 02
2
The state of IRPGO (3 remaining work items)
> On Jun 1, 2016, at 1:46 PM, Sean Silva <chisophugis at gmail.com> wrote:
>
>
>
> On Tue, May 31, 2016 at 6:02 PM, Frédéric Riss <friss at apple.com <mailto:friss at apple.com>> wrote:
>
>> On May 24, 2016, at 5:21 PM, Sean Silva <chisophugis at gmail.com <mailto:chisophugis at gmail.com>> wrote:
>>
>>
>>
>> On
2016 May 25
2
The state of IRPGO (3 remaining work items)
It sounds to me we are likely to converge on the following:
1) Making IR/llvm based PGO the default;
2) Enhance -fcoverage-mapping such that it automatically turns on FE based
instrumentation
3) if -fcoverage-mapping is used together with -fprofile-instr-generate,
-fcoverage-mapping serves as a switch to turn on FE based instrumetnation
All the above are transparent to users.
The following are
2016 Jun 01
4
The state of IRPGO (3 remaining work items)
> On May 24, 2016, at 5:21 PM, Sean Silva <chisophugis at gmail.com> wrote:
>
>
>
> On Tue, May 24, 2016 at 3:41 PM, Vedant Kumar <vsk at apple.com <mailto:vsk at apple.com>> wrote:
>
> > On May 23, 2016, at 8:56 PM, Xinliang David Li <davidxl at google.com <mailto:davidxl at google.com>> wrote:
> >
> > On Mon, May 23, 2016 at
2016 Jun 02
4
The state of IRPGO (3 remaining work items)
> On Jun 2, 2016, at 12:10 AM, Sean Silva <chisophugis at gmail.com> wrote:
>
>
>
> On Wed, Jun 1, 2016 at 5:46 PM, Frédéric Riss <friss at apple.com <mailto:friss at apple.com>> wrote:
>
>> On Jun 1, 2016, at 1:46 PM, Sean Silva <chisophugis at gmail.com <mailto:chisophugis at gmail.com>> wrote:
>>
>>
>>
>> On
2014 May 12
3
[LLVMdev] Questions about LLVM PGO and autoFDO
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
2016 Jun 13
2
The state of IRPGO (3 remaining work items)
Quick update. I've gotten derailed from posting a patch for this due to
focusing on higher priority PGO inlining work. No ETA.
-- Sean Silva
On Fri, Jun 3, 2016 at 6:06 PM, Sean Silva <chisophugis at gmail.com> wrote:
>
>
> On Thu, Jun 2, 2016 at 6:41 PM, Xinliang David Li <davidxl at google.com>
> wrote:
>
>>
>>
>> On Thu, Jun 2, 2016 at 5:30
2015 May 28
3
[LLVMdev] RFC - Improvements to PGO profile support
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:
$
2016 May 24
6
The state of IRPGO (3 remaining work items)
> On May 23, 2016, at 8:56 PM, Xinliang David Li <davidxl at google.com> wrote:
>
> On Mon, May 23, 2016 at 8:23 PM, Sean Silva <chisophugis at gmail.com> wrote:
> Jake and I have been integrating IRPGO on PS4, and we've identified 3 remaining work items.
>
> Sean, thanks for the write up. It matches very well with what we think as well.
+ 1
> - Driver
2016 Mar 09
3
PGO question
Hi,
I have a question regarding PGO.
I collected profile data with the instrumentation build
(-fprofile-instr-generate) and provided for PGO optimization in the second
build (with -fprofile-instr-use=xxx.profdata). This works fine.
Then I tried to provide the profile data to opt using the option
-pgo-instr-use, but this causes an error with the message: "Not an IR level
instrumentation
2015 May 22
0
[LLVMdev] RFC - Improvements to PGO profile support
On Fri, May 22, 2015 at 11:16 AM, Dario Domizioli
<dario.domizioli at gmail.com> wrote:
> Hi all,
>
> I am a bit confused about the documentation of the format of the profile
> data file.
>
> The Clang user guide here describes it as an ASCII text file:
> http://clang.llvm.org/docs/UsersManual.html#sample-profile-format
>
> Whereas the posts above and the