Dehao explained that the data needs to merged during link time to give
meaningful diagnostics.
Ok for google branch.
David
On Wed, Mar 12, 2014 at 3:55 PM, Xinliang David Li wrote:
> Why is it not enough to emit warnings during build time when source
> code changes signifcantly?
>
I think the right way to fix this is to wrap the call to early_inliner
and check the TODO flags. See execute_function_todo:
if (flags & TODO_cleanup_cfg)
{
cleanup_tree_cfg ();
if (!(flags & TODO_update_ssa_any) && need_ssa_update_p (cfun))
flags |= TODO_update_ssa;
- compute_inline_parameters (cgraph_get_node
> (current_function_decl), true);
> - early_inliner ();
> + early_inline ();
>autofdo::afdo_annotate_cfg (promoted_stmts);
> compute_function_frequency ();
>update_ssa (TODO_update_ssa);
Is this update still needed
The patch is ok.
David
On Thu, Mar 20, 2014 at 1:10 PM, Dehao Chen wrote:
> On Thu, Mar 20, 2014 at 1:02 PM, Xinliang David Li wrote:
>> On Thu, Mar 20, 2014 at 12:40 PM, Dehao Chen wrote:
>>> Patch updated to add a wrapper early_inline function
>>>
&g
Add comment to the new function. init_node_map is better invoked after
the link step to avoid creating entries with for dead nodes.
Ok if large perf testing is fine.
David
On Tue, Mar 25, 2014 at 3:38 PM, Dehao Chen wrote:
> This patch refactors LIPO fixup related code to move it into a
> stand
is cgraph_init_gid_map called after linking?
David
On Wed, Mar 26, 2014 at 3:54 PM, Dehao Chen wrote:
> Patch updated, passed performance tests.
>
> Dehao
>
> On Tue, Mar 25, 2014 at 4:03 PM, Xinliang David Li wrote:
>> Add comment to the new function. init_node_map is
ok.
On Thu, Mar 27, 2014 at 9:02 AM, Dehao Chen wrote:
> On Wed, Mar 26, 2014 at 4:05 PM, Xinliang David Li wrote:
>> is cgraph_init_gid_map called after linking?
>
> Oh, forgot that part. It's interesting that the test can pass without
> another cgraph_init_gid_map
looks fine.
David
On Thu, Apr 3, 2014 at 10:56 AM, Dehao Chen wrote:
> This patch updates SSA after VPT transformation. This is needed
> because compute_inline_parameters will ICE without updated SSA.
>
> Testing on-going.
>
> OK for google-4_8?
>
> Thanks,
> Dehao
>
> Index: gcc/auto-profile.c
ok (after fixing the format -- a function name starts a new line in
function def).
David
On Mon, Apr 7, 2014 at 12:49 PM, Dehao Chen wrote:
> This patch calls add_fake_edge for the AutoFDO+LIPO path.
>
> Bootstrapped and passed regression test and performance test.
>
> OK for google-4_8?
>
> Th
Looks good to me.
David
On Thu, Apr 10, 2014 at 2:04 PM, Teresa Johnson wrote:
> This patch fixes an issue where self-recursive calls were missed
> during ipa inlining in LIPO compiles, since the resolved nodes were
> not checked. When a self-recursive call was inlined incorrectly,
> ipa_inline
This looks fine. LIPO has similar change too. Other directions worth
looking into:
1) To model icache effect better, weighted callee size need to be
used with profile. The weight for BB may look like: min(1,
FREQ(BB)/FREQ(ENTRY)).
2) When function splitting is turned on, are any inline heuristi
Do you witness similar problems with LTO +FDO?
My concern is it can be tricky to get the register pressure estimate
right. The register pressure problem is created by downstream
components (code motions etc) but only exposed by the inliner. If you
want to get it 'right' (i.e., not exposing the pr
On Fri, Apr 18, 2014 at 10:26 AM, Jan Hubicka wrote:
> Hello,
>> Honza,
>> Seeing your recent patches relating to inliner heuristics for LTO,
>> I thought I should mention some related work I'm doing.
>>
>> By way of introduction, I've recently joined the IBM LTC's PPC
>> Toolchain team, working
with different quality thus different weights.
Another challenge is how to quantify cycle savings/overhead more
precisely. With that, we can abandon the threshold based scheme -- any
callsite with a net saving will be considered.
David
> Honza
>>
>> Aaron
>>
>> On Fr
On Fri, Apr 18, 2014 at 12:51 PM, Jan Hubicka wrote:
>> What I've observed on power is that LTO alone reduces performance and
>> LTO+FDO is not significantly different than FDO alone.
>>
>> I agree that an exact estimate of the register pressure would be a
>> difficult problem. I'm hoping that som
On Fri, Apr 18, 2014 at 2:16 PM, Jan Hubicka wrote:
>> On Fri, Apr 18, 2014 at 12:27 PM, Jan Hubicka wrote:
>> >> What I've observed on power is that LTO alone reduces performance and
>> >> LTO+FDO is not significantly different than FDO alone.
>> > On SPEC2k6?
>> >
>> > This is quite surprising,
Bin, when will the patch for the generic pass be available for review?
David
On Wed, Apr 9, 2014 at 7:27 PM, Bin.Cheng wrote:
> On Thu, Apr 10, 2014 at 8:18 AM, Wei Mi wrote:
>> Hi,
>>
>> For the testcase 1.c
>>
>> #include
>>
>> double a[1000];
>>
>> __m128d foo1() {
>> __m128d res;
>> re
On Tue, Apr 22, 2014 at 1:17 PM, Jan Hubicka wrote:
>> This looks fine. LIPO has similar change too. Other directions worth
>> looking into:
>>
>> 1) To model icache effect better, weighted callee size need to be
>> used with profile. The weight for BB may look like: min(1,
>> FREQ(BB)/FREQ(ENT
On Tue, Dec 11, 2012 at 1:49 AM, Richard Biener
wrote:
> On Mon, Dec 10, 2012 at 10:07 PM, Mike Stump wrote:
>> On Dec 10, 2012, at 12:42 PM, Xinliang David Li wrote:
>>> I have not measured the CFI size impact -- but conceivably it should
>>> be larger -- which is un
52340 618545
delta -1.5% 15.5% -0.006%
parser-move 81244 15788 334003
parser-push 80684 16332 333987
delta -0.7% 3.4% -0.005%
On Tue, Dec 11, 2012 at 9:14 AM, Xinliang David Li wrote:
> On Tue, Dec 11, 2012 at 1:49 AM, Richard Biener
> wrote:
>> On Mon, Dec 10, 2012
Some SPEC2k performance number (with 3 runs on core2):
Push wins over move on 3 benchmarks. Others are noises.
perlbmk : ~+1.9%
gap: ~+1.4%
vortex:~ +0.7%
David
On Tue, Dec 11, 2012 at 2:53 PM, Xinliang David Li wrote:
> The following the O2 size data from SPEC2k. Note that w
On Wed, Dec 12, 2012 at 8:37 AM, Jan Hubicka wrote:
>> I noticed in prologue/epilogue, GCC prefers to use MOVs followed by a
>> SP adjustment instead of a sequence of pushes/pops. The preference to
>> the MOVs are good for old CPU micro-architectures (before pentium-4,
>> K10), because it breaks t
Honza, can you explain each change and point to the reference?
thanks,
David
On Wed, Dec 12, 2012 at 8:37 AM, Jan Hubicka wrote:
>> I noticed in prologue/epilogue, GCC prefers to use MOVs followed by a
>> SP adjustment instead of a sequence of pushes/pops. The preference to
>> the MOVs are good
On Wed, Dec 12, 2012 at 10:30 AM, Jan Hubicka wrote:
> Concerning 1push per cycle, I think it is same as K7 hardware did, so move
> prologue should be a win.
>> > Index: config/i386/i386.c
>> > ===
>> > --- config/i386/i386.c (revisi
On Wed, Dec 12, 2012 at 4:16 PM, Xinliang David Li wrote:
> On Wed, Dec 12, 2012 at 10:30 AM, Jan Hubicka wrote:
>> Concerning 1push per cycle, I think it is same as K7 hardware did, so move
>> prologue should be a win.
>>> >
On Wed, Dec 12, 2012 at 5:19 PM, Jan Hubicka wrote:
>> > libcall is not faster up to 8KB to rep sequence that is better for
>> > regalloc/code
>> > cache than fully blowin function call.
>>
>> Be careful with this. My recollection is that REP sequence is good for
>> any size -- for smaller size,
9:14PM -0800, Xinliang David Li wrote:
>> On Wed, Dec 12, 2012 at 5:19 PM, Jan Hubicka wrote:
>> >> > libcall is not faster up to 8KB to rep sequence that is better for
>> >> > regalloc/code
>> >> > cache than fully blowin function call.
>
A couple of comments:
1) please dump with source location if possible. What is the use of
the information if there is no line number
2) Please do not use the existing dump report -- Loop 1,2,3 etc means
nothing to user
3) The optimization report should be standardized with some template
(similar t
This looks good to me for google branches. Useful for trunk too.
David
On Wed, Dec 19, 2012 at 12:08 PM, Rong Xu wrote:
> Hi,
>
> This patch adds the supprot of atomic update the profile counters.
> Tested with google internal benchmarks and fdo kernel build.
>
> Thanks,
>
> -Rong
>
> 2012-12-19
It depends on the value distribution .
David
On Thu, Dec 20, 2012 at 11:30 AM, Rong Xu wrote:
> On Wed, Dec 19, 2012 at 5:22 PM, Rong Xu wrote:
>> On Wed, Dec 19, 2012 at 5:04 PM, wrote:
>>> The change in gcov-io.h is from a different patch.
>>
>> sorry. here is the patch for gcov-io.h:
>>
>
Ahmad has helped doing some atom performance testing (ChromeOS
benchmarks) with this patch. In summary, there is no statistically
significant regression seen. There is one improvement of about +1.9%
(v8 benchmark) which looks real.
David
On Wed, Dec 12, 2012 at 9:24 AM, Xinliang David Li wrote
Kernel build does not link in libgcc, which defines the function.
David
On Fri, Dec 21, 2012 at 8:31 AM, Teresa Johnson wrote:
> On Wed, Dec 19, 2012 at 12:11 PM, Rong Xu wrote:
>> Hi,
>>
>> This patch updates the support for FDO build in linux kernel for gcc 4.7.
>> Tested with 2.6.34 kernel a
Is there a way to tell if the program is going to be multi-threaded?
If not, it might be useful to introduce a compiler option such as -fmt
which also enables -lpthread. Using tricks like weakrefs can
introduce unnecessary runtime overhead.
David
On Fri, Dec 28, 2012 at 8:26 AM, David Edelsohn
It would be great if this can make into gcc4.8. The patch has close to
0 impact on code stability.
David
On Fri, Dec 28, 2012 at 11:32 AM, Rong Xu wrote:
> Hi Honza,
>
> In the other thread of discussion (similar patch in google-4_7
> branch), you said you were thinking if to let this patch into
Ok for google branch, but it might be better to warn this at compile
time (more discussion needed for the trunk version).
David
On Wed, Jan 2, 2013 at 4:58 PM, Rong Xu wrote:
> Hi,
>
> This patch fixes an issue in r194725. The call to atmoic builtin
> is emmitted regardless of -fprofile-gen-atom
Is it better to change the option to something like:
split_segment|nosplit-segment
or split_segment=yes|no
David
On Thu, Jan 3, 2013 at 5:41 PM, Sriraman Tallam wrote:
> Hi Rong,
>
> The following patch modifies the behaviour of the linker plugin to
> not create a separate segment for cold s
ok.
thanks,
David
On Fri, Jan 4, 2013 at 9:32 AM, Paul Pluzhnikov wrote:
> Back-port revision 194909 to google/gcc-4_7 branch:
> http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194909
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54526
>
> Google ref: b/7427993
>
> Index: gcc/testsuite/g++.old
AM, Rong Xu wrote:
>> The code looks fine to me. Please consider David's comments about the
>> option name.
>>
>> -Rong
>>
>> On Thu, Jan 3, 2013 at 9:14 PM, Xinliang David Li wrote:
>>> Is it better to change the option to something lik
I saw only one test case fix patch from Paolo in trunk. Does this
patch include more local fixes?
David
On Fri, Jan 4, 2013 at 3:03 PM, Paul Pluzhnikov wrote:
> On Fri, Jan 4, 2013 at 9:41 AM, Xinliang David Li wrote:
>> ok.
>
> The patch as sent caused some breakage, I had
ok.
thanks,
David
On Fri, Jan 4, 2013 at 3:38 PM, Paul Pluzhnikov wrote:
> On Fri, Jan 4, 2013 at 3:27 PM, Xinliang David Li wrote:
>> I saw only one test case fix patch from Paolo in trunk. Does this
>> patch include more local fixes?
>
> There was an earlier patch which
Need to document the parameter in doc/invoke.texi.
Ok with that change.
David
On Fri, Jan 4, 2013 at 5:28 PM, Rong Xu wrote:
> Hi,
>
> This patch adjusts the single target indirect call promotion heuristics.
> (1) it uses bb counts (bb_all), instead of count "all" which only counts
> the target
I noticed that the traverse and traverse_noresize method takes
Argument as the first template parameter. It should be moved to be the
second after the callback. In most of the cases, the type of the
Argument can be deduced from the callsite, so that the user only need
to specify the callback:
ht->
Looks fine. Why adding tests that are expected to fail? Are these
tests passing with trunk?
David
On Tue, Jan 15, 2013 at 9:33 PM, Maxim Kuvyrkov
wrote:
> David,
>
> This patch adds tests for inlining and devirtualization optimizations, some
> of which are already in google's gcc-4_7 branch.
ok.
thanks,
David
On Fri, Feb 8, 2013 at 6:57 PM, Harshit Chopra wrote:
> 2013-02-08 Harshit Chopra
>
> Porting revisions r183548, r183888, r186118, r192231, r193381.
>
> diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
> index ab416ff..04b973f 100644
> --- a/gcc/c-famil
ok. The same problem exists in google/main too.
David
On Tue, Feb 12, 2013 at 1:38 PM, Teresa Johnson wrote:
> This patch fixes a bad merge from google/integration to google/4_7.
>
> Passes regression tests. Ok for google/4_7?
>
> Thanks,
> Teresa
>
> 2013-02-12 Teresa Johnson
>
> * c
when split_segment is specified but the API does not exist, why not
making it fatal ? Will it crash at some point when the null pointer is
referenced later?
David
On Wed, Feb 13, 2013 at 4:19 PM, Sriraman Tallam wrote:
> Hi,
>
>I have attached a patch for the reordering plugin to display
> a
ok.
thanks,
David
On Wed, Feb 13, 2013 at 4:41 PM, Sriraman Tallam wrote:
> Updated patch attached.
>
> Thanks
> Sri
>
> On Wed, Feb 13, 2013 at 4:39 PM, Sriraman Tallam wrote:
>> On Wed, Feb 13, 2013 at 4:32 PM, Xinliang David Li
>> wrote:
>>> when
On Thu, Feb 14, 2013 at 10:18 AM, Matt wrote:
> The attached patches do two things:
> 1. Backports a fix from trunk that eliminates bogus warning traces. On my
> current codebase which links ~40MB of C++ with LTO, the bogus warning traces
> are literally hundreds of lines.
>
What is the trunk rev
Ok for the google branch -- please provide the patch details in svn
commit message (note that ChangeLog is not needed any more for the
branch).
David
On Thu, Feb 14, 2013 at 11:53 AM, Matt Hargett wrote:
> On Feb 14, 2013, at 10:40 AM, Xinliang David Li wrote:
>
>> On Thu, Feb 14
On Tue, Oct 18, 2011 at 3:56 PM, wrote:
> On 2011/10/18 22:52:33, davidxl wrote:
>>
>> http://codereview.appspot.com/5272048/diff/18001/tree-asan.c
>> File tree-asan.c (right):
>
>
> http://codereview.appspot.com/5272048/diff/18001/tree-asan.c#newcode325
>>
>> tree-asan.c:325: base = build_addr (
It will be weird to put the instrumentation pass inside loop opt,
besides memory loads which are loop invariants and redundant stores in
loop should be handled by pre/pde.
+cc Richard Guenther
You may want to ask the middle-end maintainer to review your code at
this point if you want it to be in
On Tue, Oct 18, 2011 at 3:48 PM, Rong Xu wrote:
> Suppress verbose notes/warnings printed in FDO-use compilation.
> (1) Add option -fprofile-use-verbose.
Gcc currently does not emit informational messages on high level
transformations such as inlining, value profiling transformations (ic
promotio
On Wed, Oct 19, 2011 at 12:02 PM, wrote:
> Minimized the crash to this:
>
> struct Foo {
> unsigned bf1:1;
> unsigned bf2:1;
> unsigned bf3:1;
> };
>
> void foo (struct Foo *ob) {
> ob->bf2 = 1;
> }
>
>
>
> D.2731_4 = &ob_1(D)->bf2;
> __asan_base_addr.2 = (long unsigned int) D.2731_4;
> D.273
what kind of failures?
David
On Wed, Oct 19, 2011 at 2:04 PM, wrote:
> On 2011/10/19 20:38:35, kcc wrote:
>>
>> Added code to avoid bitfields.
>
> Is there anything I should know about splitting basic blocks in the
> presence of EH?
> Currently, asan fails on 483.xalancbmk, 453.povray and 450.s
On Thu, Oct 20, 2011 at 1:21 AM, Richard Guenther
wrote:
> On Thu, Oct 20, 2011 at 1:33 AM, Andi Kleen wrote:
>> x...@google.com (Rong Xu) writes:
>>
>>> After some off-line discussion, we decided to use a more general approach
>>> to control the printing of optimization messages/warnings. We wil
While discussion for trunk version is still going, it is ok for google branches.
thanks,
David
On Wed, Oct 19, 2011 at 4:28 PM, Rong Xu wrote:
> After some off-line discussion, we decided to use a more general approach
> to control the printing of optimization messages/warnings. We will
> intro
On Thu, Oct 20, 2011 at 12:53 PM, Andi Kleen wrote:
>> This warnings/notes are caused
>> by inconsistent profile due to data race (which is currently common in
>> multi-thread programs),
>
> I never quite understood why the gcov counters are not simply marked
> __thread. This would make the profil
There are two proposals here. One is -fopt-info which prints out
informational notes to stderr, and the other is -fopt-report which is
more elaborate form of dump files. Are you object to both or just the
opt-report one? The former is no different from any other
informational notes we already have
On Sun, Oct 23, 2011 at 3:18 AM, Richard Guenther
wrote:
> On Fri, Oct 21, 2011 at 6:48 PM, Xinliang David Li wrote:
>> There are two proposals here. One is -fopt-info which prints out
>> informational notes to stderr, and the other is -fopt-report which is
>> more elabora
> Well, you seem to keep not reading what I write. I am not opposed
> to adding -fopt-info/report nor to funnel messages to stdout/err. What
> I am opposed is the way you want to introduce them. I want you to
> fix what we dump into dump files, so that both -fopt-report and -fopt-info
> can be i
I am hoping that too:) Yes, I will try to do it when I find some time.
David
On Wed, Oct 26, 2011 at 1:37 AM, Richard Guenther
wrote:
> On Tue, Oct 25, 2011 at 9:30 PM, Xinliang David Li wrote:
>>
>>
>> On Tue, Oct 25, 2011 at 1:02 AM, Richard Guenther
>> wrote:
&
that means some existing bugs get exposed. Your previous version
simply skipped the target mem refs. You will need to debug the
problem a little more.
David
On Tue, Nov 1, 2011 at 5:26 AM, wrote:
> On 2011/10/31 06:08:34, davidxl wrote:
>>
>> http://codereview.appspot.com/5303083/diff/1/gcc/pa
On Tue, Nov 1, 2011 at 12:16 PM, Diego Novillo wrote:
> On 11-11-01 15:11 , konstantin.s.serebry...@gmail.com wrote:
>>
>> Diego mentioned that we can move the asan pass somewhere to the very
>> end, just before lowering to RTL.
>> Where would be this blessed place?
>> Does it still have TARGET_ME
On Tue, Nov 1, 2011 at 12:26 PM, Martin Jambor wrote:
> Hi,
>
> sorry that I'm not using the fancy web tool but I do not want to use
> my google account and gmail address in particular for work-related
> stuff.
>
> On Tue, Nov 01, 2011 at 06:05:46PM +, davi...@google.com wrote:
>>
>
> ...
>
>>
On Tue, Nov 1, 2011 at 12:41 PM, Diego Novillo wrote:
> On 11-11-01 15:34 , Xinliang David Li wrote:
>
>>> Right before pass_expand? In init_optimization_passes(), look for
>>> NEXT_PASS
>>> (pass_expand). That's RTL generation. Somewhere before th
Ok for google/main when the option is documented in doc/invoke.texi
and a Changlog file is provided.
David
On Tue, Nov 1, 2011 at 5:24 PM, wrote:
> So, do you have any other suggestions before the first commit?
>
> http://codereview.appspot.com/5272048/
>
On Tue, Nov 1, 2011 at 2:53 AM, Richard Guenther
wrote:
> On Tue, Nov 1, 2011 at 1:46 AM, Teresa Johnson wrote:
>> This patch is for google-main only.
>>
>> Tested with bootstrap and regression tests.
>>
>> Print unroll and peel factors along with loop source position under
>> -fopt-info.
>>
>>
Ok for google/main.
1) may be better to omit the const iteration count for complete unroll message
2) Instead of dumping loop header count, is it better to dump
pre-header count -- it gives an idea of how often the loop is entered.
The loop header count can be derived from loop average iteration a
> http://codereview.appspot.com/5303083/diff/1/gcc/tree-tsan.c#newcode911
>>
>> gcc/tree-tsan.c:911: bbd->has_sb = 0;
>> Where is the code that instrument function calls?
>
> I do not instrument calls. Instead I instrument func entry/exit.
>
How are calls to locking and synchronization functions t
On Thu, Nov 3, 2011 at 6:31 AM, wrote:
> On 2011/11/01 16:59:04, davidxl wrote:
>>
>> that means some existing bugs get exposed.
>
> It is quite likely.
>
>> Your previous version
>> simply skipped the target mem refs.
>
> Hummm... how can non-handling of some expressions lead to crashes? I
> wou
Ok for google branches.
David
On Fri, Nov 4, 2011 at 10:13 AM, Rong Xu wrote:
> Don't emit the type info if a function's context type is not
> output.
>
> For google branch only.
>
> Tested with internal benchmark suite with -g.
>
> 2011-11-04 Rong Xu
>
> * gcc/dwarf2out.c (dwarf2out_
ok.
David
On Fri, Nov 4, 2011 at 10:39 AM, Rong Xu wrote:
> Suppress another LIPO notes. Move it under fopt-info.
>
> For google branch only.
>
> Tested with internal branchmark suite.
>
> 2011-11-04 Rong Xu
>
> * gcc/c-family/c-opts.c: move the notes under fopt-info.
>
> Index: gcc/c
Hi, the following patch is a follow up to the one posted here
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01293.html.
The new patch is a header only change and can greatly reduce rodata
section size for some programs.
Ok for trunk after testing?
thanks,
David
cl
Description: Binary data
st
thanks. The attached is the revised patch.
David
On Sat, Nov 5, 2011 at 11:52 AM, Paolo Carlini wrote:
> On 11/05/2011 07:32 PM, Xinliang David Li wrote:
>>
>> Hi, the following patch is a follow up to the one posted here
>> http://gcc.gnu.org/ml/gcc-patches/2009-05/msg0129
Ping .. (the Nov 7 cutoff date is close ..).
thanks,
David
On Sat, Nov 5, 2011 at 12:22 PM, Xinliang David Li wrote:
> thanks. The attached is the revised patch.
>
> David
>
> On Sat, Nov 5, 2011 at 11:52 AM, Paolo Carlini
> wrote:
>> On 11/05/2011 07:32 PM,
tested
on linux/x86-64. Ok for trunk (or better fix suggested)?
thanks,
David
2011-11-05 Xinliang David Li
* cp/decl.c (cp_finish_decl): Prevent cleanups from
being garbage collected before being released.
Index: cp/decl.c
1, argv=0x7fffd3c8)
at /usr/local/google/davidxl/dev/gcc/tot/gcc/toplev.c:2006
#25 0x00cd97e0 in main (argc=71, argv=0x7fffd3c8) at
/usr/local/google/davidxl/dev/gcc/tot/gcc/main.c:36
On Mon, Nov 7, 2011 at 1:56 AM, Richard Guenther
wrote:
> On Mon, Nov 7, 2011 at 8:53 AM, Xinli
On Mon, Nov 7, 2011 at 1:30 PM, Sharad Singhai wrote:
> Honza,
> Sorry, I forgot about this. Could you please put this on your TODO list?
>
> David,
> While a proper fix is pending for the trunk, we need this interim fix
> internally. Okay for google/main?
ok.
thanks,
David
>
> Thanks,
> Sharad
ok for google/main.
David
On Mon, Nov 7, 2011 at 2:40 PM, Rong Xu wrote:
> Fix the build warning introduced in r180971.
>
> This is for google branch only.
>
> Tested with build.
>
> 2011-11-07 Rong Xu
>
> * gcc/dwarf2out.c (dwarf2out_decl): fix mixed declarations and code.
>
> Index:
Here is the revised patch. Bootstrap and regression tested on linux/x86-64.
Honza, can you comment on the implication of this change?
thanks,
David
On Mon, Nov 7, 2011 at 2:09 PM, Richard Guenther
wrote:
> On Mon, Nov 7, 2011 at 5:41 PM, Xinliang David Li wrote:
>> Here is the st
Looks like it is fixed already, so there is no need for this patch.
David
On Wed, Nov 9, 2011 at 12:36 AM, Richard Guenther
wrote:
> On Tue, Nov 8, 2011 at 6:10 PM, Xinliang David Li wrote:
>> Here is the revised patch. Bootstrap and regression tested on linux/x86-64.
>>
&g
On Thu, Nov 10, 2011 at 4:24 PM, Kostya Serebryany wrote:
>
>
> On Thu, Nov 10, 2011 at 4:00 PM, wrote:
>>
>> Have you run through SPEC, and SPEC06 with this change? What is the
>> instrumentation overhead using gcc?
>
> I don't think anyone of us ever run spec with tsan.
> Mostly because this wi
On Sun, Aug 19, 2012 at 9:59 PM, Teresa Johnson wrote:
> On Sat, Aug 18, 2012 at 1:19 AM, Jan Hubicka wrote:
>>
>> > +{
>> > + cs_prg->num = cs_tprg->num;
>> > + /* Allocate the working set array for the merged
>> > summary. */
>> > +
>
> So I definitely preffer 2 or 3 over 1. David has experience with 3. How well
> does
> it work for LIPO?
>
This (lack of locking, races) is not a new problem. There is no
synchronization in libgcov for profile update/merge at both thread and
process level. Thread level data races leads to inco
> If this approach seems like it is feasible, then we could stick with
> the current approach of emitting the working set array in the summary,
> mitigating it somewhat by doing the sum_all based scaling of the
> counter values, then in a follow on patch restructure the merging code
> to delay the
I was mistaken here -- gcov_open actually uses locking via fcntl
interface -- so we do need to find a way to solve the summary update
synchronization problem when it is separate out of the per-file update
loop.
David
On Mon, Aug 20, 2012 at 12:03 PM, Andi Kleen wrote:
> Xinliang David
On Mon, Aug 20, 2012 at 10:29 PM, Jan Hubicka wrote:
>> On Mon, Aug 20, 2012 at 6:27 PM, Jan Hubicka wrote:
>> >> Xinliang David Li writes:
>> >> >
>> >> > Process level synchronization problems can happen when two processes
>> >> &g
On Mon, Aug 20, 2012 at 11:33 PM, Jan Hubicka wrote:
>>
>> This is useful for large applications with a long tail. The
>> instruction working set for those applications are very large, and
>> inliner and unroller need to be aware of that and good heuristics can
>> be developed to throttle aggressi
On Tue, Aug 21, 2012 at 12:34 AM, Jan Hubicka wrote:
>> Teresa has done some tunings for the unroller so far. The inliner
>> tuning is the next step.
>>
>> >
>> > What concerns me that it is greatly inaccurate - you have no idea how many
>> > instructions given counter is guarding and it can diffe
The patch is needed to handle more options that will causes invalid
LIPO module grouping. The new option handled is -fsized-delete.
David
On Thu, Aug 23, 2012 at 11:32 AM, David Li wrote:
> Index: coverage.c
> ===
> --- coverage.c
On Thu, Aug 23, 2012 at 2:01 PM, Teresa Johnson wrote:
> This patch is for google branches only.
>
> This is the patch I plan to apply after reverting an earlier set of
> patches ported over from trunk that addressed the same problem but
> were causing some performance regressions. This is a narro
Ok for now but some follow up may be needed.
thanks,
David
On Thu, Aug 23, 2012 at 4:21 PM, Teresa Johnson wrote:
> On Thu, Aug 23, 2012 at 3:33 PM, Xinliang David Li wrote:
>> On Thu, Aug 23, 2012 at 2:01 PM, Teresa Johnson wrote:
>>> This patch is for google branches onl
I don't see any code where a string table is declared nor created ...
David
On Fri, Aug 24, 2012 at 2:26 PM, Chris Manghane wrote:
> Also, what did you mean by there being missing string table management code?
>
>
> On Fri, Aug 24, 2012 at 2:23 PM, wrote:
>>
>>
>> Ok, I fixed most of the probl
On Fri, Aug 24, 2012 at 3:56 PM, wrote:
>
> http://codereview.appspot.com/6427063/diff/11002/gcc/gcov-io.h
> File gcc/gcov-io.h (right):
>
> http://codereview.appspot.com/6427063/diff/11002/gcc/gcov-io.h#newcode688
> gcc/gcov-io.h:688: gcov_unsigned_t index; /* The corresponding string
> table
89,11 @@ slpeel_make_loop_iterate_ntimes (struct loop
>>> >>>>> *loop
>>> >>>>> gsi_remove (&loop_cond_gsi, true);
>>> >>>>>
>>> >>>>> loop_loc = find_loop_location (loop);
>>> >>>&
Can you make definition of location_adhoc_data available in both
libcpp and gcc? In gcc side, the data structure will be annotated
with GTY(). The root global variables should also be visible in gcc
side.
David
On Tue, Sep 11, 2012 at 10:06 PM, Dehao Chen wrote:
> Now I think we are facing a mo
On Wed, Sep 12, 2012 at 2:13 AM, Richard Guenther
wrote:
> On Wed, Sep 12, 2012 at 7:06 AM, Dehao Chen wrote:
>> Now I think we are facing a more complex problem. The data structure
>> we use to store the location_adhoc_data are file-static in linemap.c
>> in libcpp. These data structures are not
ck is in the map, it can still be
> GCed as soon as it's not reachable from DECL_INITIAL.
>
> I've tested this on some very large C++ files (each one takes more
> than 10s to build), the memory consumption does not see noticeable
> increase/decrease.
>
> Thanks,
> Deh
ehao
>
> On Thu, Sep 13, 2012 at 1:18 AM, Xinliang David Li wrote:
>> On Wed, Sep 12, 2012 at 10:05 AM, Dehao Chen wrote:
>>> There are two parts that needs memory management:
>>>
>>> 1. The BLOCK structure. This is managed by GC. I originally thought
>&
It is very important to make sure -g does not affect code gen ---
people do release build with -g with optimization, and strip the
binary before sending it to production machines ..
David
On Thu, Sep 13, 2012 at 6:33 AM, Robert Dewar wrote:
> On 9/13/2012 8:00 AM, Richard Guenther wrote:
>
>> Be
601 - 700 of 1034 matches
Mail list logo
