On Fri, Aug 30, 2013 at 7:50 AM, Teresa Johnson wrote:
> Can someone review and ok the attached patch for trunk? It has been
> bootstrapped and tested on x86-64-unknown-linux-gnu, and tested by
> enabling -freorder-blocks-and-partition enabled for a
> profiledbootstrap as well.
>
> (Honza, see mor
On Tue, Sep 24, 2013 at 5:31 AM, Jan Hubicka wrote:
>> Hi Honza,
>>
>> I am finally getting back to working on this after a few weeks of
>> working on some other priorities.
>
> I am also trying to return to this, so good timming ;)
> Martin has got smaller C++ programs (Inkscape) to not touch col
.
This patch fixes this problem.
-Rong
2013-09-26 Rong Xu
* ipa-inline-analysis.c (estimate_function_body_sizes): fix
the size estimation for builtin_expect.
Index: ipa-inline-analysis.c
===
--- ipa-inline
2013-09-26 Rong Xu
* params.def (DEFPARAM): New.
* params.def: New.
* predict.c (tree_predict_by_opcode): Alternate
probablity hirate for builtin_expect.
Index: params.def
===
--- params.def
On Thu, Sep 26, 2013 at 2:54 PM, Jan Hubicka wrote:
>> > As for COMDAT merging, i would like to see the patch. I am experimenting
>> > now with a patch to also privatize COMDATs during -fprofile-generate to
>> > avoid problems with lost profiles mentioned above.
>> >
>>
>> Do you mean you privati
roduce
>>> an extra relation expr which has non-zero size/time. The end result
>>> is: for w/ and w/o builtin_expect, we have different size/time estimation
>>> for early inlining.
>>>
>>> This patch fixes this problem.
>>>
>>> -Rong
d result
>> is: for w/ and w/o builtin_expect, we have different size/time estimation
>> for early inlining.
>>
>> This patch fixes this problem.
>>
>> -Rong
>
>> 2013-09-26 Rong Xu
>>
>> * ipa-inline-analysis.c (estimate_function_body_siz
I don't quite understand here. We use the profile-generate memory
consumption to estimate the profile use memory consumption.
we still have -g/-gmlt in profile-use compilation. Will this change
effectively under estimate the memory use in the use phrase?
-Rong
On Fri, Sep 27, 2013 at 11:50 AM, Te
ought to get analyze_brprob working again. It was always
> useful to get such a data.
>>
>>
>> This patch sets the alternate hirate probability for
>> builtin_expert
>> to 90%. With the alternate hirate, we measured performance
>>
Hi,
Current default probability for builtin_expect is 0.9996.
This makes the freq of unlikely bb very low (4), which
suppresses the inlining of any calls within those bb.
We used FDO data to measure the branch probably for
the branch annotated with builtin_expert.
For google internal benchmar
Hi,
builtin_expect should be a NOP in size_estimation. Indeed, the call
stmt itself is 0 weight in size and time. But it may introduce
an extra relation expr which has non-zero size/time. The end result
is: for w/ and w/o builtin_expect, we have different size/time estimation
for inlining.
This p
ping.
On Fri, Sep 27, 2013 at 3:56 PM, Rong Xu wrote:
> Hi,
>
> builtin_expect should be a NOP in size_estimation. Indeed, the call
> stmt itself is 0 weight in size and time. But it may introduce
> an extra relation expr which has non-zero size/time. The end result
>
ping.
On Fri, Sep 27, 2013 at 3:53 PM, Rong Xu wrote:
> Hi,
>
>
>
> Current default probability for builtin_expect is 0.9996.
> This makes the freq of unlikely bb very low (4), which
> suppresses the inlining of any calls within those bb.
>
> We used FDO data to meas
Comments are inlined.
Attached is the new patch.
Thanks,
-Rong
On Tue, Sep 25, 2012 at 2:25 PM, Xinliang David Li wrote:
> On Mon, Sep 24, 2012 at 2:42 PM, Rong Xu wrote:
>> Hi,
>>
>> This is for google branches only.
>> It fix the lino number checksum mis
On Wed, Oct 2, 2013 at 9:08 AM, Jan Hubicka wrote:
>> > Hi,
>> >
>> >
>> >
>> > Current default probability for builtin_expect is 0.9996.
>> > This makes the freq of unlikely bb very low (4), which
>> > suppresses the inlining of any calls within those bb.
>> >
>> > We used FDO data to measure t
attached the new patch. OK for check in?
On Wed, Oct 2, 2013 at 9:12 AM, Jan Hubicka wrote:
>> > Hi,
>> >
>> > builtin_expect should be a NOP in size_estimation. Indeed, the call
>> > stmt itself is 0 weight in size and time. But it may introduce
>> > an extra relation expr which has non-zero siz
Here is the new patch. Honaz: Could you take a look?
Thanks,
-Rong
On Wed, Oct 2, 2013 at 2:31 PM, Jan Hubicka wrote:
>> Thanks for the suggestion. This is much cleaner than to use binary parameter.
>>
>> Just want to make sure I understand it correctly about the orginal hitrate:
>> you want to
Radhakrishnan wrote:
> On 10/02/13 23:49, Rong Xu wrote:
>>
>> Here is the new patch. Honaz: Could you take a look?
>>
>> Thanks,
>>
>> -Rong
>>
>> On Wed, Oct 2, 2013 at 2:31 PM, Jan Hubicka wrote:
>>>>
>>>> Thanks
Hi,
An earlier patch (r203167) changed the default probability for
builtin_expect to 90%.
It does not work properly for the following case:
while (__builin_expect (expr, 1)) { }
W/o builtin_expect, the exit probability is 9% while w/
builtin_expect, the exit probability is 10%.
It seems to
The trunk version of this patch is submitted for review.
David: can we have this patch for google/gcc-4_8 branch first?
It tested with regression and google internal benchmarks.
Thanks,
-Rong
2013-10-11 Rong Xu
* predict.c (tree_predict_by_opcode): Bump the
estimiated
I want to differentiate the cases w/o and w/ builtin.
If I take the max, they will be the same (91%).
-Rong
On Fri, Oct 11, 2013 at 2:26 PM, Xinliang David Li wrote:
> Why this 'percent += 4' instead of taking the max?
>
> David
>
> On Fri, Oct 11, 2013 at 2:10 PM, Ron
ok. that makes sense.
On Fri, Oct 11, 2013 at 2:41 PM, Xinliang David Li wrote:
> Should it be max + some_delta then?
>
> David
>
> On Fri, Oct 11, 2013 at 2:32 PM, Rong Xu wrote:
>> I want to differentiate the cases w/o and w/ builtin.
>> If I take the max
hitrate = REG_BR_PROB_BASE;
+ break;
+}
+}
+}
+}
+ predict_edge (then_edge, PRED_BUILTIN_EXPECT, hitrate);
}
/* Try "pointer heuristic."
A comparison ptr == 0 is predicted as false.
On Fri, Oc
Attached is the patchset 2. It takes the max to two hitrates then does
the incremental.
On Fri, Oct 11, 2013 at 2:01 PM, Rong Xu wrote:
> Hi,
>
> An earlier patch (r203167) changed the default probability for
> builtin_expect to 90%.
> It does not work properly for the
Hi,
For google gcc-4_8 branch only.
This is fixes the NULL pointer dereference in copy_tree_r due to empty
varpool_node returned.
Passed the ICE compilation. Other tests are ongoing.
Thanks,
-Rong
2013-10-14 Rong Xu
* cp/semantics.c (finish_compound_literal): Put static var to
seems fine to me for google branches.
-Rong
On Tue, Oct 22, 2013 at 10:51 AM, Dehao Chen wrote:
> This is fixing a LIPO bug when there -fexception is on.
>
> When compilation is finished, compile_file calls
> dw2_output_indirect_constants, which may generate decls like
> DW.ref.__gxx_personality
Hi,
This patch writes out ggc_memory to gcda files.
Google branches only. Test is ongoing. OK to check-in after test passes?
-Rong
2013-10-25 Rong Xu
* contrib/profile_tool (ModuleInfo): write out ggc_memory to gcda file.
* gcc/gcov-io.c (gcov_read_module_info): Ditto
libgcov.c is the main file to generate libgcov.a. This single source generates
21 object files and then archives to a library. These objects are of
very different purposes but they are in the same file guarded by various macros.
The source file becomes quite large and its readability becomes very
l
BTW, this part of patch only does the re-factoring work.
I haven't finished the porting of profile-tool part of patch to the
trunk. They should be in a separate patch anyway.
-Rong
On Mon, Nov 4, 2013 at 2:43 PM, Rong Xu wrote:
> Honza, Thanks for the comments!
> Attached is the patc
-3.34%+5.75% --
On Mon, Nov 25, 2013 at 11:19 AM, Rong Xu wrote:
> On Mon, Nov 25, 2013 at 2:11 AM, Richard Biener
> wrote:
>> On Fri, Nov 22, 2013 at 10:49 PM, Rong Xu wrote:
>>> On Fri, Nov 22, 2013 at 4:03 AM, Richard Biener
>>> wrote:
>>>>
gcov_pow2_profiler.o (ex
> ./lib64/gcc/x86_64-suse-linux/4.8/libgcov.a)
> 115 0 0 115 73 _gcov_one_value_profiler.o (ex
> ./lib64/gcc/x86_64-suse-linux/4.8/libgcov.a)
> 122 0 0 122 7a _gcov_indirect_call_profiler.o (ex
> ./lib64/
On Wed, Dec 18, 2013 at 9:28 AM, Xinliang David Li wrote:
>>>
>>> #ifdef L_gcov_merge_ior
>>> /* The profile merging function that just adds the counters. It is given
>>> - an array COUNTERS of N_COUNTERS old counters and it reads the same
>>> number
>>> - of counters from the gcov file.
On Fri, Dec 6, 2013 at 6:23 AM, Jan Hubicka wrote:
>> @@ -325,6 +311,9 @@ static struct gcov_summary all_prg;
>> #endif
>> /* crc32 for this program. */
>> static gcov_unsigned_t crc32;
>> +/* Use this summary checksum rather the computed one if the value is
>> + *non-zero. */
>> +static
My bad.
Thanks for the fix!
-Rong
On Thu, Jan 9, 2014 at 11:47 AM, H.J. Lu wrote:
> On Wed, Jan 8, 2014 at 2:33 PM, Rong Xu wrote:
>> On Fri, Dec 6, 2013 at 6:23 AM, Jan Hubicka wrote:
>>>> @@ -325,6 +311,9 @@ static struct gcov_summary all_prg;
>>>> #endi
7;key' field in gcov_fn_info to reduce the
instrumented objects size.
2015-09-29 Rong Xu
* gcc/coverage.c (build_fn_info_type): Remove 'key'
field. (build_fn_info): Ditto.
(coverage_obj_fn): Ditto.
* libgcc/libgcov.h (struct gcov_fn_info): Ditto.
fi_ptr)
> length = GCOV_TAG_FUNCTION_LENGTH;
> - else
> -length = 0;
> }
>
> The removal of 'else' path seems wrong.
>
> David
>
>
> On Tue, Sep 29, 2015 at 1:46 PM, Rong Xu wrote:
>> Hi,
>>
>> Thi
;
gcov_unsigned_t cc1_uncompressed_strlen;
char *saved_cc1_strings;
The new saved_cc1_strings are zlib compressed string.
Tested with google internal benchmarks.
Thanks,
-Rong
2015-10-05 Rong Xu
* gcc/Makefile.in (gcov-dump): link with zlib
(gcov-tool): Ditto.
* gcc/auto-profile.c
> + /* cc1_uncompressed_strlen field */
>field = build_decl (BUILTINS_LOCATION, FIELD_DECL,
>NULL_TREE, get_gcov_unsigned_t ());
>DECL_CHAIN (field) = fields;
>fields = field;
>
>
> Why do we need to store uncompressed string leng
> On Tue, Oct 6, 2015 at 9:26 AM, Rong Xu wrote:
>> On Mon, Oct 5, 2015 at 5:33 PM, Xinliang David Li wrote:
>>>unsigned ggc_memory = gcov_read_unsigned ();
>>> + unsigned marker = 0, len = 0, k;
>>> + char **string_array, *saved_cc1_strings;
&g
Here is the patch set 2 that integrates David's comments. Note that
this uses the combined strlen (i.e. encoding compressed and
uncompressed strlen into one gcov_unsigned_t).
Testing is ongoing.
-Rong
On Tue, Oct 6, 2015 at 11:30 AM, Rong Xu wrote:
> It's 1:3 to 1:4 in the prog
Hi,
This patch fixes the issue when using gcov-tool to merge LIPO profiles
after we compressing the module infomration . We should not decompress
the string as the compressed string should be written directly to the
profile later. Tested with some LIPO profiles.
Thanks,
-Rong
2015-12-01 Rong
ath before.
>
> On Tue, Dec 1, 2015 at 4:34 PM, Rong Xu wrote:
>>
>> Hi,
>>
>> This patch fixes the issue when using gcov-tool to merge LIPO profiles
>> after we compressing the module infomration . We should not decompress
>> the string as the compress
Hi,
This patch makes gcov-tool build configurable. A new configure option
--disable-gcov-tool is added to disable the build.
It also fixes some build issues for mingw.
Tested with regression and bootstrap. mingw test is ongoing.
OK to check in if mingw build passes?
Thanks,
-Rong
gcov_tool_
This patch makes the build of gcov-tool configurable. It checks if
ftw.h is available. For mingw build, it provides ftw functionality by
using FindFirstFile/FindNextFile/FindClose API.
Tested with and without --disable-gcov-tool.
Thanks,
-Rong
2014-09-02 Rong Xu
* gcc/Makefile.in
w source and weight parameter -- especially the weight.
Will do.
> 3) How do you deal with integer overflow ?
This is good question. gcvo_type is (typically) long long. I thought
the count value will not be nearly close to the max of long long.
(We did see overflow in compiler, but that'
at 10:48 AM, Rong Xu wrote:
> On Fri, Nov 8, 2013 at 10:22 AM, Xinliang David Li wrote:
>> in libgcov-driver.c
>>
>>> /* Flag when the profile has already been dumped via __gcov_dump(). */
>>> static int gcov_dump_complete;
>>
>
On Fri, Nov 8, 2013 at 11:02 AM, Xinliang David Li wrote:
> On Fri, Nov 8, 2013 at 10:48 AM, Rong Xu wrote:
>> On Fri, Nov 8, 2013 at 10:22 AM, Xinliang David Li
>> wrote:
>>> in libgcov-driver.c
>>>
>>>> /* Flag when the profile has already been
On Fri, Nov 8, 2013 at 11:30 AM, Xinliang David Li wrote:
> On Fri, Nov 8, 2013 at 11:21 AM, Rong Xu wrote:
>> On Fri, Nov 8, 2013 at 11:02 AM, Xinliang David Li
>> wrote:
>>> On Fri, Nov 8, 2013 at 10:48 AM, Rong Xu wrote:
>>>> On Fri, Nov 8, 2013 at 10:2
On Mon, Nov 11, 2013 at 7:02 AM, Jan Hubicka wrote:
>> 2013-11-04 Rong Xu
>>
>> * libgcc/libgcov.c: Delete as part of re-factoring.
>> * libgcc/libgcov-profiler.c (__gcov_interval_profiler): Moved from
>> libgcov.c
>>
On Mon, Nov 11, 2013 at 7:17 AM, Jan Hubicka wrote:
>> Here is the patch that includes profile-tool.
>> Profile-tool now has two functions: merge and rewrite. I'll add diff later.
>>
>> Compiler is tested with spec2006 and profiledbootstrap.
>> profile-tool is tested with spec2006 profiles.
>
> Hi
A question about the newly added global variable function_counter.
Does it have to be a global? Can I make it a file static, within macro
L_gcov_time_profiler? I don't find a use other than in
__gcov_time_profiler().
thanks,
-Rong
On Mon, Nov 11, 2013 at 9:52 AM, Martin Liška wrote:
> On 11 N
Thanks. I'll have this change included in my libgcov.c re-re-factoring patch.
-Rong
On Tue, Nov 12, 2013 at 10:18 AM, Martin Liška wrote:
> Hi Rong,
> you are right, that's the only usage and so that you can declare it
> static.
>
> Thank you,
> Martin
>
>
function to libgcov-interface.c and made it under
L_gcov_flush (newly added).
So if you need this function, you have to enable L_gcov_flush in the
libgcc/Makefile.in.
Thanks,
-Rong
On Mon, Nov 11, 2013 at 10:19 AM, Rong Xu wrote:
> On Mon, Nov 11, 2013 at 7:02 AM, Jan Hubicka wrote:
>&
On Mon, Nov 18, 2013 at 2:15 PM, Jan Hubicka wrote:
> Hi,
> this patch fixes problem we noticed with Martin Liska where gcov_dump is
> called
> several times per execution of firefox (on each fork and exec). This causes
> runs to be large and makes functions executed once per program to be
> co
statically link libatomic.a. Andrew: Do you have any
suggestion? Or should we let the user link to libatomic.a if the
builtins are not expanded?
Is this OK for trunk?
Thanks,
-Rong
On Mon, Jan 7, 2013 at 12:55 PM, Rong Xu wrote:
> Function __gcov_indirect_call_profiler_atomic (which con
On Tue, Nov 19, 2013 at 5:11 PM, Andrew Pinski wrote:
> On Tue, Nov 19, 2013 at 5:02 PM, Rong Xu wrote:
>> Hi all,
>>
>> I merged this old patch with current trunk. I also make the following changes
>> (1) not using weak references. Now every *profile_atomic() has it&
ofile-arcs|fprofile-generate*|coverage:-lgcov\
+ " GCOV_ATOMIC_SPEC "} " SANITIZER_SPEC " \
%{!nostdlib:%{!nodefaultlibs:%(link_ssp) %(link_gcc_c_sequence)}}\
%{!nostdlib:%{!nostartfiles:%E}} %{T*} }}"
On Wed, Nov 20, 2013 at 1:04 PM, Joseph S. Myers
OK. Sorry for miss-reading the message.
In that case, linking in libatomic becomes a separate issue. We don't
need to touch gcc.c in this patch.
Thanks,
-Rong
On Wed, Nov 20, 2013 at 2:19 PM, Andrew Pinski wrote:
> On Wed, Nov 20, 2013 at 2:07 PM, Rong Xu wrote:
>> Joseph and
-dump'.
>
> David
>
> On Mon, Nov 18, 2013 at 12:24 PM, Rong Xu wrote:
>> Hi, all
>>
>> This is the new patch for gcov-tool (previously profile-tool).
>>
>> Honza: can you comment on the new merge interface? David posted some
>> comments in an earli
counters.
The improvement can be significant for highly threaded programs -- we
are seeing 7x speedup in coverage test run for some non-trivial google
applications.
Tested with bootstrap.
Thanks,
-Rong
2013-11-21 Rong Xu
* gcc/doc/invoke.texi (coverage-exec_once): Add document
On Fri, Nov 22, 2013 at 4:03 AM, Richard Biener
wrote:
> On Fri, Nov 22, 2013 at 4:51 AM, Rong Xu wrote:
>> Hi,
>>
>> This patch injects a condition into the instrumented code for edge
>> counter update. The counter value will not be updated after reaching
>> va
On Mon, Nov 25, 2013 at 2:11 AM, Richard Biener
wrote:
> On Fri, Nov 22, 2013 at 10:49 PM, Rong Xu wrote:
>> On Fri, Nov 22, 2013 at 4:03 AM, Richard Biener
>> wrote:
>>> On Fri, Nov 22, 2013 at 4:51 AM, Rong Xu wrote:
>>>> Hi,
>>>>
>>&
Hi,
I ported the indirect-call topn target profile from google branch. It
implements the algorithm described in "Value profiling and
optimization" by Brad Calder and Peter Feller. This patch is about the
instrumentation. When --param=indir-call-topn-profile=1 is specified,
we will use indirection-
Hi,
I ported the indirect-call topn target profile from google branch. It
implements the algorithm described in "Value profiling and
optimization" by Brad Calder and Peter Feller. This patch is the
runtime support.
Tested with gcc regression tests and the instrumentation patch (in a
separated pat
On Mon, Oct 6, 2014 at 12:21 PM, Jan Hubicka wrote:
>> On Mon, Oct 6, 2014 at 11:22 AM, Jan Hubicka wrote:
>> > Rong,
>> > Would be possible to use topn profiler to get resonale histograms for
>> > switch
>> > expansion, too? In that case it may make sense to have value version of
>> > it as w
performance triaging and reducing the fdo
training set size (where similar inputs can be pruned).
Tested with spec2006 profiles.
Thanks,
-Rong
2014-10-07 Rong Xu
* gcc/gcov-tool.c (profile_overlap): New driver function
to compute profile overlap
no file to reconstruct the CFG. That needs some work.
-Rong
>
> Honza
>>
>> The resulting score is a value ranging from 0.0 to 1.0 where 0.0 means
>> no match and 1.0 mean a perfect match.
>>
>> This tool can be used in performance triaging and reducing the fdo
&g
Hi
This patch moves the gcov-dump functionality to gcov-tool (which is
installed by default).
The options are exactly the same as before. The difference is instead of calling
"gcov-dump ...", we now call "gcov-tool dump ..."
gcov-dump is useful in debugging fdo issues. I think it would be very
he
Hi,
The attached patch fixes PR63581. The diagnosis is in the bug report.
Google ref b/17759776.
Tested with bootstrap and regression.
Thanks,
-Rong
63581_patch
Description: Binary data
(working copy)
@@ -1,3 +1,6 @@
+2014-10-17
+ * g++.dg/tree-prof/pr63581.C: New test.
+
2014-10-17 Marek Polacek
PR c/63543
On Fri, Oct 17, 2014 at 2:54 PM, Rong Xu wrote:
> Hi,
>
> The attached patch fixes PR63581. The diagnosis is in the bug report.
> Google ref b/17759776.
>
ifunc support is hard-coded as false for BIONIC. This patch removes
this check and let
configure decide whether it should have ifunc support.
Thanks,
-Rong
ifunc_diff
Description: Binary data
This patch looks good to me.
-Rong
On Thu, Jun 5, 2014 at 12:45 PM, Teresa Johnson wrote:
> (cc'ing a few additional people to help with review as David is out
> and I'm not sure Rong is available)
>
> This patch greatly reduces the memory overhead of the new COMDAT fixup
> analysis, by changing
This looks fine to me.
-Rong
On Thu, Jun 12, 2014 at 11:23 AM, Teresa Johnson wrote:
> These two patches fix multiple ICE that occurred due to DFE being
> recently enabled after AutoFDO LIPO linking.
>
> Passes regression and internal testing. Ok for Google/4_8?
>
> Teresa
>
> 2014-06-12 Teresa
Here is patch that ports our work on FDO linux kernel build support to
gcc-4_9. With this patch, kernel will use the libgcov functions to
dump the gcda files.
This patch also enables LIPO build. But the module grouping is not
computed online. We will use gcov-tool to do this offline.
Tested with
Hi,
This patch implements the use phase of indirect-call-topn-profile that
promotes multiple targets of indirect-calls. It addresses pr/45631.
The main idea is to use current speculation framework, with a vector
of direct edges (sorted by the probability). The trick part is the we
have multiple
.
It disables the may-uninit check if the warning will not be
emitted.
Tested with bootstrap, regressions test and google internal
benchmarks.
Thanks,
-Rong
2013-05-21 Rong Xu
* gcc/tree-ssa-uninit.c (gate_warn_uninitialized): Disable if
may-uninit warning will not emitted
This patch fixes a bug in exposed in LIPO build (ICE in copy tree node).
Tested with bookstrap and google internal benchmarks.
-Rong
2013-05-24 Rong Xu
Google ref b/8963414.
* gcc/tree-inline.c (add_local_variables): Not map
to deleted debug expression.
Index: gcc
to it.
Tested with problematic file and regression test.
Trunk may also have the same issue, but I need to work on a testcase.
Thanks,
-Rong
2014-10-02 Rong Xu
* gcc/cfgrtl.c (emit_barrier_after_bb): Append footer instead of
overwriting.
Index: gcc/cfg
Hi,
This patch fixes a bad merge in r199218.
Removing cgraph noded in early-ipa should be allowed.
Otherwise, we got ICE in tree-eipa_sra with
-freorder-funtions=callgraph (without -fripa)
Tested with regressions and google banchmarks.
Thanks,
-Rong
patch.diff
Description: Binary data
We have seen the issue before. It does fail the profile boostrap as it
reads a wrong gcda file.
I thought it had been fixed. (The fix was as David mentioned, setting
the default value of the parameter to 0).
-Rong
On Tue, Jul 30, 2013 at 12:02 PM, Xinliang David Li wrote:
> I need to understand
, Xinliang David Li wrote:
> Ok. Rong, can you help commit the parameter default setting patch?
>
> thanks,
>
> David
>
> On Tue, Jul 30, 2013 at 12:48 PM, Rong Xu wrote:
>> We have seen the issue before. It does fail the profile boostrap as it
>> reads a wrong gc
The following patch forces the command line match for -ansi option
in LIPO use build. Otherwise, it gets various undefined symbol errors.
This is exposed in LIPO random grouping test.
Tested with google internal benchmarks and gcc regression test.
2013-07-30 Rong Xu
* gcc/coverage.c
This patch fixed a bug in lipo varpool node linking.
C++ FE drops the initializer if it's not used in this TU. For current
varpool linking may
resolve the varpool node to the one with null initializer.
-Rong
Index: l-ipo.c
===
---
Hi,
This is the patch that implements a new module grouping.
It's based on module level graph and simple inclusion based algorithm.
Tests are ongoing with google internal benchmarks and spec2k, spec2k6.
Thanks,
-Rong
2013-02-25 Rong Xu
* libgcc/dyn-ipa.c (struct dyn_cgraph)
internal benchmarks.
-Rong
2013-03-05 Rong Xu
* libgcc/dyn-ipa.c (__gcov_lipo_weak_inclusion):
changed from __gcov_lipo_strict_inclusion.
(init_dyn_call_graph): Ditto.
(ps_add_auxiliary): Ditto.
(modu_edge_add_auxiliary): Ditto.
* gcc/tree-profile.c
that contain
profile data to merge.
Histogram is recomputed (i.e. preicise). Module grouping information
in LIPO is approximation.
Thanks,
-Rong
2013-04-08 Rong Xu
* contrib/profile_merge.py: An offline profile merge tool.
Index: contrib/profile_merge.py
Revised copyright info.
-Rong
2013-04-08 Rong Xu
* contrib/profile_merge.py: An offline profile merge tool.
Index: contrib/profile_merge.py
===
--- contrib/profile_merge.py(revision 0)
+++ contrib/profile_merge.py
Hi,
Patch set 3 for offline profile merge tool.
(1) Rename to profile_tool for future function expansion.
(2) Install to bin/ directory for easy user access.
Thanks,
-Rong
2013-04-09 Rong Xu
* gcc/Makefile.in: Install profile_tool to bin directory.
* contrib/profile_tool
This patch integrated Martin's comments.
-Rong
2013-04-10 Rong Xu
* contrib/profile_tool: New
* gcc/Makefile.in (GCC_INSTALL_NAME): install profile_tool
Index: contrib/profile_tool
===
--- contrib/profile
Hi,
This patch fixed lipo ICE triggered by an out-of-bound access.
This is google specific patch and tested with bootstrap and the
program exposed the issue.
Thanks,
-Rong
2014-05-08 Rong Xu
* tree-inline.c (add_local_variables): Check if the debug_expr
is a decl_node
that
checks b/w saved command lines.
Tested with the program exposed this issue and internal benchmarks.
This check never failed for instrumentation based lipo in the test.
Thanks,
-Rong
2014-05-12 Rong Xu
* coverage.c (struct string_hasher): Use const char
I think these asserts will be used by gcov-tool. So I prefer to change
them to gcov_nonruntime_assert(). I'll merge them in my new gcov-tool
patch before submitting (waiting for honaz's ok).
Thanks,
-Rong
On Thu, May 22, 2014 at 7:09 AM, Teresa Johnson wrote:
> On Thu, Jan 16, 2014 at 2:41 PM,
oogle/main so that a better diff can be done
> 4) libdriver-profiler.c -- make the function ordering the same as in
> google/main would be helpful.
sure. I'll do this two items. Will send an updated patch soon.
>
> thanks,
>
> David
>
> On Wed, Jan 15, 2014 at 10:03 AM, Rong
Ping.
-Rong
On Mon, Jan 13, 2014 at 12:43 PM, Rong Xu wrote:
> Hi,
>
> This patch implements gcov-tool, a offline profile processing tool.
> This version supports merging two profiles with weights, and scaling
> the profile with a floating-point / fraction weight.
>
> Earl
so some comments needs
> to be added in dyn-ipa.c to make sure the value should be doubly
> updated).
>
> David
>
> On Fri, Jan 17, 2014 at 11:15 AM, Rong Xu wrote:
>> Hi,
>>
>> This patch port the gcov-tool work to google/gcc-4_8 branches.
>>
>>
Hi,
This patch is for google/gcc-4_8 branch. It fixes a regression in
earlier libgcov refactoring.
Thanks,
-Rong
2014-01-23 Rong Xu
* libgcov-driver.c (__gcov_get_profile_prefix): Always emit
this function.
Index: libgcov-driver.c
-time module grouping computation and reuses the one
comes with the profiles (which is user editable).
Tested with profiles from google internal benchmarks.
-Rong
2014-01-29 Rong Xu
* gcc/gcov-tool.c (mod_name_id): New type of the hashtable entry.
(mod_name_id_htab_hash): Hash
Comments are inlined. New patch attached to this email.
-Rong
On Thu, Jan 30, 2014 at 12:39 PM, Xinliang David Li wrote:
> On Wed, Jan 29, 2014 at 4:24 PM, Rong Xu wrote:
>> Hi,
>>
>> The attached patch adds some new features to gcov-tool. It aims to
>> rewrite LIPO
Thanks for catching this, and the fix.
OK for google branch.
-Rong
On Fri, Jan 31, 2014 at 2:46 PM, Hán Shěn (沈涵) wrote:
> Hi Rong, while building for arm toolchain on chromeos, GCOV_LOCKED is
> not defined, which leads to redefinition of cs_all, this is observed
> on google/gcc-4_8 branch.
>
>
Here is the revised patch that integrates Teresa' comments.
Ok for checking in?
-Rong
On Thu, Jan 30, 2014 at 1:20 PM, Rong Xu wrote:
> Comments are inlined. New patch attached to this email.
>
> -Rong
>
> On Thu, Jan 30, 2014 at 12:39 PM, Xinliang David Li
> wrote:
>
1 - 100 of 178 matches
Mail list logo
