o: hiradi...@msn.com
> CC: de...@google.com; i.palac...@samsung.com; davi...@google.com;
> hubi...@ucw.cz; gcc@gcc.gnu.org; v.bari...@samsung.com; dnovi...@google.com;
> seb...@gmail.com
> Subject: Re: AutoFDO profile toolchain is open-sourced
>
>>> Yes, it will. But it'
> > Yes, it will. But it's not well tuned at all. I will start tuning it
> > if I have free cycles. It would be great if opensource community can
> > also contribute to this tuning effort.
>
> If you could outline portions of code which needs tuning, rewriting, that
> will help get started in thi
> Date: Fri, 8 May 2015 11:19:12 -0700
> Subject: Re: AutoFDO profile toolchain is open-sourced
> From: de...@google.com
> To: i.palac...@samsung.com
> CC: davi...@google.com; hubi...@ucw.cz; gcc@gcc.gnu.org;
> v.bari...@samsung.com; d
On Fri, May 8, 2015 at 2:00 AM, Ilya Palachev wrote:
> On 11.04.2015 01:49, Xinliang David Li wrote:
>>
>> On Fri, Apr 10, 2015 at 3:43 PM, Jan Hubicka wrote:
LBR is used for both cfg edge profiling and indirect call Target value
profiling.
>>>
>>> I see, that makes sense ;) I gue
On 11.04.2015 01:49, Xinliang David Li wrote:
On Fri, Apr 10, 2015 at 3:43 PM, Jan Hubicka wrote:
LBR is used for both cfg edge profiling and indirect call Target value
profiling.
I see, that makes sense ;) I guess if we want to support profile collection
on targets w/o this feature we could
On Mon, Apr 27, 2015 at 7:37 AM, Ilya Palachev wrote:
> Hi,
>
> On 21.04.2015 20:25, Dehao Chen wrote:
>>
>> OTOH, the most important patch (insn-level discriminator support) is
>> not in yet. Cary has just retired. Do you know if anyone would be
>> interested in porting insn-level discriminator s
On Thu, Apr 23, 2015 at 10:31 PM, Jan Hubicka wrote:
>
> > > It converts with the attached patches, but there's still some problem
> > > parsing the data:
> > >
> > > % ./create_gcov -binary loop -gcov_version 1 -gcov loop.gcda
> > > -gcov_version 0x500e
> > > % gcc50 -O2 -fprofile-use loop.c
>
Hi,
On 21.04.2015 20:25, Dehao Chen wrote:
OTOH, the most important patch (insn-level discriminator support) is
not in yet. Cary has just retired. Do you know if anyone would be
interested in porting insn-level discriminator support to trunk?
Do you mean r210338, r210397, r210523, r214745 ?
Ca
> > It converts with the attached patches, but there's still some problem
> > parsing the data:
> >
> > % ./create_gcov -binary loop -gcov_version 1 -gcov loop.gcda -gcov_version
> > 0x500e
> > % gcc50 -O2 -fprofile-use loop.c
> > loop.c:1:0: warning: '/home/andi/src/autofdo/loop.gcda' is version
Thanks, I'll forward the patches to quipper team.
On Tue, Apr 21, 2015 at 8:47 PM, Andi Kleen wrote:
> On Wed, Apr 22, 2015 at 05:15:47AM +0200, Andi Kleen wrote:
>> On Tue, Apr 21, 2015 at 01:52:18PM -0700, Dehao Chen wrote:
>> > Andi,
>> >
>> > Thanks for the patches. Turns out that the first 3
On Wed, Apr 22, 2015 at 05:15:47AM +0200, Andi Kleen wrote:
> On Tue, Apr 21, 2015 at 01:52:18PM -0700, Dehao Chen wrote:
> > Andi,
> >
> > Thanks for the patches. Turns out that the first 3 patches are already
> > in, the correct upstream quipper repository is:
> >
> > https://chromium.googlesou
On Tue, Apr 21, 2015 at 01:52:18PM -0700, Dehao Chen wrote:
> Andi,
>
> Thanks for the patches. Turns out that the first 3 patches are already
> in, the correct upstream quipper repository is:
>
> https://chromium.googlesource.com/chromiumos/platform2/+/master/chromiumos-wide-profiling/
>
> The
nstructions -o $perfdata
>>> $SRC/SingleSource/Benchmarks/Linpack/Output/linpack-pc.simple
>>>
>>> autofdo/usr/bin/create_gcov
>>> --binary=$SRC/SingleSource/Benchmarks/Linpack/Output/linpack-pc.simple
>>> --profile=$perfdata --gcov=$gcov
>>>
/linpack-pc.simple
>> --profile=$perfdata --gcov=$gcov
>>
>> }
>>
>>
>> hth,
>> -Aditya
>>
>>
>>> From: a...@firstfloor.org
>>> To: i.palac...@samsung.com
>>> CC: dnovi...@google.com;
Andi,
Thanks for the patches. Turns out that the first 3 patches are already
in, the correct upstream quipper repository is:
https://chromium.googlesource.com/chromiumos/platform2/+/master/chromiumos-wide-profiling/
The last 3 patches seem to be local hacks. Do you want any of them in?
I just d
>> From: a...@firstfloor.org
>> To: i.palac...@samsung.com
>> CC: dnovi...@google.com; gcc@gcc.gnu.org; davi...@google.com;
>> hubi...@ucw.cz; seb...@gmail.com; de...@google.com; v.bari...@samsung.com
>> Subject: Re: AutoFDO pro
b...@gmail.com; de...@google.com; v.bari...@samsung.com
> Subject: Re: AutoFDO profile toolchain is open-sourced
> Date: Tue, 21 Apr 2015 07:25:10 -0700
>
> Ilya Palachev writes:
>>
>> But why create_gcov does not inform about that (no branch events were
>> found)? It crea
On Tue, Apr 21, 2015 at 10:27:49AM -0700, Dehao Chen wrote:
> In that case, we should get quipper fixed upstream to accommodate new
> format. (Maybe they already fixed it, I will do a batch sync to make
> quipper up-to-date).
>From a quick look at
http://git.chromium.org/gitweb/?p=chromiumos/pla
In that case, we should get quipper fixed upstream to accommodate new
format. (Maybe they already fixed it, I will do a batch sync to make
quipper up-to-date).
Dehao
On Tue, Apr 21, 2015 at 10:24 AM, Andi Kleen wrote:
>> > BTW the biggest problem with autofdo currently is that it is
>> > quite b
I'll get to it soon. When will stage1 close?
OTOH, the most important patch (insn-level discriminator support) is
not in yet. Cary has just retired. Do you know if anyone would be
interested in porting insn-level discriminator support to trunk?
Dehao
On Tue, Apr 21, 2015 at 8:59 AM, Jan Hubicka
> > BTW the biggest problem with autofdo currently is that it is
> > quite bitrotten and supports only several years old perf.
> > So all of this above will only work with old distributions,
> > unless you compile an old perf utility first.
>
> Do you mean newer perf does not support LBR (-b) any
> You can use dump_gcov to show a text version of the profile dump and
> check if the profile data makes sense. If your program is just a very
> tight single loop, the current implementation in trunk may not yield
> good results because it does not have discriminator support. Try the
> google-4_9 b
On Tue, Apr 21, 2015 at 7:25 AM, Andi Kleen wrote:
> Ilya Palachev writes:
>>
>> But why create_gcov does not inform about that (no branch events were
>> found)? It creates empty gcov file and says nothing :(
>>
>> Moreover, in the mentioned README it is said that perf should also be
>> executed
On Tue, Apr 21, 2015 at 6:42 AM, Ilya Palachev wrote:
> On 21.04.2015 14:57, Diego Novillo wrote:
>>
>> >From the autofdo page: https://github.com/google/autofdo
>>
>> [ ... ]
>> Inputs:
>>
>> --profile: PERF_PROFILE collected using linux perf (with last branch
>> record).
>> In order to collect t
Ilya Palachev writes:
>
> But why create_gcov does not inform about that (no branch events were
> found)? It creates empty gcov file and says nothing :(
>
> Moreover, in the mentioned README it is said that perf should also be
> executed with option -e BR_INST_RETIRED:TAKEN.
Standard perf doesn't
On 21.04.2015 14:57, Diego Novillo wrote:
>From the autofdo page: https://github.com/google/autofdo
[ ... ]
Inputs:
--profile: PERF_PROFILE collected using linux perf (with last branch record).
In order to collect this profile, you will need to have an Intel CPU that
have last branch record (LB
On Tue, Apr 21, 2015 at 6:33 AM, Ilya Palachev wrote:
> ping?
>
> On 15.04.2015 10:41, Ilya Palachev wrote:
>>
>> Hi,
>>
>> One more question.
>>
> Does anybody know with which options should the perf be executed so that to
> collect appropriate data for the autofdo converter?
>From the autofdo p
ping?
On 15.04.2015 10:41, Ilya Palachev wrote:
Hi,
One more question.
Does anybody know with which options should the perf be executed so that
to collect appropriate data for the autofdo converter?
I obtain the same data for different programs, and it seems to be empty
(1600 Bytes).
They h
Hi,
One more question.
On 10.04.2015 23:39, Jan Hubicka wrote:
I must say I did not even try running AutoFDO myself (so I am happy to hear
it works).
I tried to use executable create_gcov built from AutoFDO repository at
github.
The problem is that the data generated by this program has size
On Fri, Apr 10, 2015 at 3:43 PM, Jan Hubicka wrote:
>> LBR is used for both cfg edge profiling and indirect call Target value
>> profiling.
> I see, that makes sense ;) I guess if we want to support profile collection
> on targets w/o this feature we could still use one of the algorithms that
> t
On Tue, Apr 7, 2015 at 7:45 AM, Ilya Palachev wrote:
> Hi,
>
> Here are some questions about AutoFDO.
>
> On 08.05.2014 02:55, Dehao Chen wrote:
>>
>> We have open-sourced AutoFDO profile toolchain in:
>>
>> https://github.com/google/autofdo
>>
>> For GCC developers, the most important tool is cre
> LBR is used for both cfg edge profiling and indirect call Target value
> profiling.
I see, that makes sense ;) I guess if we want to support profile collection
on targets w/o this feature we could still use one of the algorithms that
try to guess edge profile from BB profile.
Honza
LBR is used for both cfg edge profiling and indirect call Target value
profiling.
David
On Fri, Apr 10, 2015 at 3:26 PM, Xinliang David Li wrote:
> LBR is used for both cfg edge profiling and indirect call Target value
> profiling.
>
> David
>
> On Apr 10, 2015 10:39 AM, "Jan Hubicka" wrote:
>>
> On Tue, Apr 7, 2015 at 9:45 AM, Ilya Palachev wrote:
> > In the mentioned README file it is said that " In order to collect this
> > profile, you will need to have an Intel CPU that have last branch record
> > (LBR) support." Is this information obsolete? Chrome Canary builds use
> > AutoFDO for
Hi,
Here are some questions about AutoFDO.
On 08.05.2014 02:55, Dehao Chen wrote:
We have open-sourced AutoFDO profile toolchain in:
https://github.com/google/autofdo
For GCC developers, the most important tool is create_gcov, which
converts sampling based profile to GCC-readable profile. Ple
35 matches
Mail list logo
