Great, I'll read more closely formatting rules next time I'll submit something.
Regards,
Selim
-Message d'origine-
De : Jeff Law [mailto:l...@redhat.com]
Envoyé : lundi 20 avril 2015 19:47
À : BELBACHIR Selim; gcc@gcc.gnu.org
Objet : Re: try_merge_delay_insn with delay list > 1
On 04/
Hi Brandon,
On Wed, 23 Jan 2013, Brandon Lucia wrote:
> I have implemented a GCC plugin that I have found useful for doing
> dynamic program analysis, debugging, and performance tuning in
> concurrent code.
>
> The plugin is called CTraps, short for Communication Traps. The main
> idea behind CT
On Tue, Apr 21, 2015 at 12:12:59PM +0200, Gerald Pfeifer wrote:
> On Wed, 23 Jan 2013, Brandon Lucia wrote:
> > I have implemented a GCC plugin that I have found useful for doing
> > dynamic program analysis, debugging, and performance tuning in
> > concurrent code.
> >
> > The plugin is called CT
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
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
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
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 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
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
> 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
> > 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
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
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
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
Hi!
On Mon, 1 Dec 2014 18:58:10 +0100, Tom de Vries wrote:
> On 01-12-14 09:43, Jakub Jelinek wrote:
> > On Mon, Dec 01, 2014 at 09:35:25AM +0100, Tom de Vries wrote:
> >> I've been adding an fn spec function attribute to some openacc builtin
> >> functions:
> >> ...
> >> diff --git a/gcc/builti
After patching linux perf. This script collects creates a coverage file (e.g.,
for linpack) which can be used for fdo.
gcov=linpack-x86.gcov
MAKE='make'
# x86
x86() {
CC=/usr/bin/gcc
CXX=/usr/bin/g++
export CFLAGS="-Ofast -g3 -static"
export CPPFLAGS=$CFLAGS
$MAKE -C $SRC/SingleSource/Benchm
We also needed to adjust the gcov_version in autofdo/gcov.cc to read
0x1 for dev branches of gcc (instead of the current 0x3430372a for
some released version of GCC):
-DEFINE_uint64(gcov_version, 0x3430372a,
+DEFINE_uint64(gcov_version, 0x1,
Sebastian
On Tue, Apr 21, 2015 at 3:33 PM, Aditya K w
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
That's correct. For trunk, gcov_version is 0x1. We defined this as a
flag so that you can actually change it via --gcov_version=0x1 instead
of changing the code.
Dehao
On Tue, Apr 21, 2015 at 1:47 PM, Sebastian Pop wrote:
> We also needed to adjust the gcov_version in autofdo/gcov.cc to read
> 0
On Tue, 21 Apr 2015, Jakub Jelinek wrote:
>> I added this to our extensions page at https://gcc.gnu.org/extensions.html
>> per the patch below.
> Shouldn't we also list the GCC Python Plugin on that page?
Yes, absolutely! David, want to suggest a patch? Or just some
wording and a link and I'll t
Ok, thanks for the tip of the flag.
You would also need to pass "-use_lbr=false" to create a gcov file for
a device that does not have LBR support.
We tried this on ARM collected profiles and we got the same speedup as
x86 collected profiles on linpack.
Sebastian
On Tue, Apr 21, 2015 at 3:53 PM
Snapshot gcc-5-20150421 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/5-20150421/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5
I have a question about inserting code into a function being compiled by
GCC. Basically I want to set a hard register at the beginning of a
function like is being done below. If I compile the program below on MIPS
the $16 register gets set to the result of alloca and even if I optimize
the routi
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
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 21/04/15 02:04 AM, Segher Boessenkool wrote:
On Tue, Apr 21, 2015 at 12:27:40AM +0200, Steven Bosscher wrote:
On Mon, Apr 20, 2015 at 10:11 PM, Vladimir Makarov wrote:
I might be wrong but I think you have a bloated code because you use
scratches. I already told several times that usage o
26 matches
Mail list logo
