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 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
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
> 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
> + /* 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
;
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
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
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.
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
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
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
(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.
>
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
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
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
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
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
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
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-
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
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
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_
eck your buildlog to see if -Wno-error is added to the command
>> line?
>
> I would preffer the libgcov.h (that is interface header to libgcov users) to
> be
> valid C++, so we still ought to fix it.
>
> Honza
OK. I will send out a patch for review.
-Rong
>>
>>
:0:
../../gcc/gcc/../libgcc/libgcov.h:184:30: warning: ISO C++ forbids
zero-size array ‘ctrs’ [-pedantic]
Can you check your buildlog to see if -Wno-error is added to the command line?
Thanks,
-Rong
On Fri, Jul 11, 2014 at 9:47 AM, Rong Xu wrote:
> I did see the warning in the bootstrap, but
I did see the warning in the bootstrap, but it did not exit the build.
I thought it was ok.
I'll have a patch for this and send for review.
-Rong
On Fri, Jul 11, 2014 at 9:13 AM, Xinliang David Li wrote:
> right.
>
> Rong, the fix would be just change ctr array size to 1. For each
> function, t
.
>
> David
>
> On Fri, Jul 11, 2014 at 1:12 AM, Christophe Lyon
> wrote:
>> On 11 July 2014 10:07, Richard Biener wrote:
>>> On Mon, May 5, 2014 at 7:17 PM, Rong Xu wrote:
>>>> Here is the updated patch. The difference with patch set 3 is
>>>>
0;
> Probably both can be size_t?
OK. I will change this too and submit.
Thanks for the quick review.
-Rong
>
> Honza
>
>>
>> Thanks,
>>
>> -Rong
>>
>> 2014-07-11 Rong Xu
Sorry. This code meant to work with the different mkdir api in
windows. I used wrong ifdef.
Here is the patch. OK for checkin?
Thanks,
-Rong
2014-07-11 Rong Xu
* gcov-tool.c (gcov_output_files): Fix build error.
Index: gcov-tool.c
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
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
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,
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
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
until
> April 29 when I go to Czech Republic for wedding and I will be back in Calgary
> at 14th.
>
>> 2014-03-03 Rong Xu
>>
>> * gcc/gcov-io.c (gcov_read_string): Make this routine available
>> to gcov-tool.
>> (gcov_sync): Ditto.
!(n_counters % 2));
>>for (i = 0; i < n_counters; i += 2)
>> -counters[1] *= f;
>
> Same question here
>
>> +counters[i + 1] = fn (counters[i + 1], data1, data2);
>> }
>
> Teresa
>
> On Tue, Feb 4, 2014 at 3:54 PM, Rong Xu wrote:
>> H
Hi,
The attached patch uses a callback function to unify the integer and
floating-point scaling in gcov-tool. (Also fix a bug in fp scaling of
ic and dc counters in earlier code).
Tested with spec2006 profiles.
OK for checking in?
Thanks,
-Rong
2014-02-04 Rong Xu
* gcc/gcov-tool.c
Hi,
The attached patch fixes the duplicated definition error in
gcov-tool.c in profiledbootstrap.
Google branch only and tested with profiledbootstrap.
Ok for checking in?
-Rong
Index: gcov-tool.c
===
--- gcov-tool.c (revision 2074
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:
>
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.
>
>
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
-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
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
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.
>>
>>
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
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
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
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
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.
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/
-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:
>>>>
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,
>>>>
>>&
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
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
-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
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
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
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&
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 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
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:
>&
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
>
>
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
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
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 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 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
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;
>>
>
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'
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
>
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
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
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
>>
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
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
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
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
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
.
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
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
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
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
===
---
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
, 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
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
1 - 100 of 178 matches
Mail list logo
