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
t exist for the compiler path before.
>
> On Tue, Dec 1, 2015 at 4:34 PM, Rong Xu <x...@google.com> wrote:
>>
>> Hi,
>>
>> This patch fixes the issue when using gcov-tool to merge LIPO profiles
>> after we compressing the module infomration . We should not d
avi...@google.com> wrote:
> On Tue, Oct 6, 2015 at 9:26 AM, Rong Xu <x...@google.com> wrote:
>> On Mon, Oct 5, 2015 at 5:33 PM, Xinliang David Li <davi...@google.com> wrote:
>>>unsigned ggc_memory = gcov_read_unsigned ();
>>> + unsigned marker =
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 <x...@google.com> wrote:
> It's 1
DECL_CHAIN (field) = fields;
>fields = field;
>
>
> Why do we need to store uncompressed string length? If there is need
> to do that, I suggest combine uncompressed length and compressed
> length into one 32bit integer. (16/16, or 17/15 split)
In theory, I don't n
;
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 <x...@google.com>
* gcc/Makefile.in (gcov-dump): link with zlib
(gcov-tool):
in gcov_fn_info to reduce the
instrumented objects size.
2015-09-29 Rong Xu <x...@google.com>
* 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.
*
gi_ptr)
> + if (gfi_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 <x...@google.com> w
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
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
216415)
+++ testsuite/ChangeLog (working copy)
@@ -1,3 +1,6 @@
+2014-10-17x...@google.com
+ * g++.dg/tree-prof/pr63581.C: New test.
+
2014-10-17 Marek Polacek pola...@redhat.com
PR c/63543
On Fri, Oct 17, 2014 at 2:54 PM, Rong Xu x...@google.com wrote:
Hi,
The attached patch fixes
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
training set size (where similar inputs can be pruned).
Tested with spec2006 profiles.
Thanks,
-Rong
2014-10-07 Rong Xu x...@google.com
* gcc/gcov-tool.c
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
in 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 x...@google.com
* gcc/gcov-tool.c (profile_overlap): New driver function
to compute profile overlap
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
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
On Mon, Oct 6, 2014 at 12:21 PM, Jan Hubicka hubi...@ucw.cz wrote:
On Mon, Oct 6, 2014 at 11:22 AM, Jan Hubicka hubi...@ucw.cz 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
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 x...@google.com
* gcc/cfgrtl.c (emit_barrier_after_bb): Append footer instead of
overwriting.
Index: gcc/cfgrtl.c
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 x...@google.com
* gcc
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
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 x...@google.com
* gcov-tool.c (gcov_output_files): Fix build error.
Index: gcov-tool.c
will change this too and submit.
Thanks for the quick review.
-Rong
Honza
Thanks,
-Rong
2014-07-11 Rong Xu x...@google.com
* gcov-tool.c (gcov_output_files): Fix build error.
Index: gcov-tool.c
===
--- gcov-tool.c
is not right.
David
On Fri, Jul 11, 2014 at 1:12 AM, Christophe Lyon
christophe.l...@linaro.org wrote:
On 11 July 2014 10:07, Richard Biener richard.guent...@gmail.com wrote:
On Mon, May 5, 2014 at 7:17 PM, Rong Xu x...@google.com wrote:
Here is the updated patch. The difference with patch set 3
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 davi...@google.com wrote:
right.
Rong, the fix would be just change ctr array size to 1. For
: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 x...@google.com wrote:
I did see the warning
(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
Thanks,
-Rong
On Fri, Jul 11, 2014 at 9:47 AM, Rong Xu x...@google.com wrote:
I did see the warning in the bootstrap, but it did not exit
This looks fine to me.
-Rong
On Thu, Jun 12, 2014 at 11:23 AM, Teresa Johnson tejohn...@google.com 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
This patch looks good to me.
-Rong
On Thu, Jun 5, 2014 at 12:45 PM, Teresa Johnson tejohn...@google.com 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
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 tejohn...@google.com wrote:
On Thu, Jan
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 x...@google.com
* 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 x...@google.com
* tree-inline.c (add_local_variables): Check if the debug_expr
for wedding and I will be back in Calgary
at 14th.
2014-03-03 Rong Xu x...@google.com
* gcc/gcov-io.c (gcov_read_string): Make this routine available
to gcov-tool.
(gcov_sync): Ditto.
* gcc/Makefile.in: Build and install gcov-tool.
* gcc/gcov-tool.c
, Rong Xu x...@google.com wrote:
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
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 x...@google.com wrote:
Comments are inlined. New patch attached to this email.
-Rong
On Thu, Jan 30, 2014 at 12:39 PM, Xinliang David Li davi...@google.com
wrote
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
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 x...@google.com
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 (沈涵) shen...@google.com 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
Comments are inlined. New patch attached to this email.
-Rong
On Thu, Jan 30, 2014 at 12:39 PM, Xinliang David Li davi...@google.com wrote:
On Wed, Jan 29, 2014 at 4:24 PM, Rong Xu x...@google.com wrote:
Hi,
The attached patch adds some new features to gcov-tool. It aims to
rewrite LIPO
the run-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 x...@google.com
* gcc/gcov-tool.c (mod_name_id): New type of the hashtable entry
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 x...@google.com
* libgcov-driver.c (__gcov_get_profile_prefix): Always emit
this function.
Index: libgcov-driver.c
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 x...@google.com wrote:
Hi,
This patch port the gcov-tool work to google/gcc-4_8 branches.
Tested with spec2006, profiledbootstrap and google internal benchmarks.
-Rong
Ping.
-Rong
On Mon, Jan 13, 2014 at 12:43 PM, Rong Xu x...@google.com 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.
Earlier discussion
) 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 Xu x...@google.com wrote:
The attached patch backports libgcov re-factoring
My bad.
Thanks for the fix!
-Rong
On Thu, Jan 9, 2014 at 11:47 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Jan 8, 2014 at 2:33 PM, Rong Xu x...@google.com wrote:
On Fri, Dec 6, 2013 at 6:23 AM, Jan Hubicka hubi...@ucw.cz wrote:
@@ -325,6 +311,9 @@ static struct gcov_summary all_prg
/gcc/x86_64-suse-linux/4.8/libgcov.a)
125 0 0 125 7d _gcov_merge_ior.o (ex
./lib64/gcc/x86_64-suse-linux/4.8/libgcov.a)
2014-01-08 Rong Xu x...@google.com
* libgcc/libgcov-driver.c (this_prg): make it local to save
bss space
On Wed, Dec 18, 2013 at 9:28 AM, Xinliang David Li davi...@google.com 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 hubi...@ucw.cz 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 Mon, Nov 25, 2013 at 11:19 AM, Rong Xu x...@google.com wrote:
On Mon, Nov 25, 2013 at 2:11 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, Nov 22, 2013 at 10:49 PM, Rong Xu x...@google.com wrote:
On Fri, Nov 22, 2013 at 4:03 AM, Richard Biener
richard.guent...@gmail.com wrote
On Mon, Nov 25, 2013 at 2:11 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, Nov 22, 2013 at 10:49 PM, Rong Xu x...@google.com wrote:
On Fri, Nov 22, 2013 at 4:03 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, Nov 22, 2013 at 4:51 AM, Rong Xu x...@google.com wrote
On Fri, Nov 22, 2013 at 4:03 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, Nov 22, 2013 at 4:51 AM, Rong Xu x...@google.com wrote:
Hi,
This patch injects a condition into the instrumented code for edge
counter update. The counter value will not be updated after reaching
value
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 x...@google.com
* gcc/doc/invoke.texi (coverage-exec_once): Add
On Tue, Nov 19, 2013 at 5:11 PM, Andrew Pinski pins...@gmail.com wrote:
On Tue, Nov 19, 2013 at 5:02 PM, Rong Xu x...@google.com 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's
) %(link_gcc_c_sequence)}}\
%{!nostdlib:%{!nostartfiles:%E}} %{T*} }}
On Wed, Nov 20, 2013 at 1:04 PM, Joseph S. Myers
jos...@codesourcery.com wrote:
On Wed, 20 Nov 2013, Rong Xu wrote:
I could do this in the SPEC
-Wl,-Bstatic -latomic -Wl,-Bdynamic
which would link libatomic
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 pins...@gmail.com wrote:
On Wed, Nov 20, 2013 at 2:07 PM, Rong Xu x...@google.com wrote
'.
David
On Mon, Nov 18, 2013 at 12:24 PM, Rong Xu x...@google.com 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 earlier email and we want to know what's your opinion.
Test
On Mon, Nov 18, 2013 at 2:15 PM, Jan Hubicka hubi...@ucw.cz 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
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 x...@google.com wrote:
Function __gcov_indirect_call_profiler_atomic (which
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
PM, Rong Xu x...@google.com wrote:
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
the 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 x...@google.com wrote:
On Mon, Nov 11, 2013 at 7:02 AM, Jan Hubicka hubi
On Mon, Nov 11, 2013 at 7:02 AM, Jan Hubicka hubi...@ucw.cz wrote:
2013-11-04 Rong Xu x...@google.com
* libgcc/libgcov.c: Delete as part of re-factoring.
* libgcc/libgcov-profiler.c (__gcov_interval_profiler): Moved from
libgcov.c
(__gcov_pow2_profiler): Ditto
On Mon, Nov 11, 2013 at 7:17 AM, Jan Hubicka hubi...@ucw.cz 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.
.
(We did see overflow in compiler, but that's because of the scaling --
some of the scaling factors are really large.)
David
On Thu, Nov 7, 2013 at 3:34 PM, Rong Xu x...@google.com wrote:
On Thu, Nov 7, 2013 at 9:40 AM, Joseph S. Myers jos...@codesourcery.com
wrote:
On Thu, 7 Nov 2013
:48 AM, Rong Xu x...@google.com wrote:
On Fri, Nov 8, 2013 at 10:22 AM, Xinliang David Li davi...@google.com wrote:
in libgcov-driver.c
/* Flag when the profile has already been dumped via __gcov_dump(). */
static int gcov_dump_complete;
inline void
set_gcov_dump_complete (void
On Fri, Nov 8, 2013 at 11:02 AM, Xinliang David Li davi...@google.com wrote:
On Fri, Nov 8, 2013 at 10:48 AM, Rong Xu x...@google.com wrote:
On Fri, Nov 8, 2013 at 10:22 AM, Xinliang David Li davi...@google.com
wrote:
in libgcov-driver.c
/* Flag when the profile has already been dumped via
On Fri, Nov 8, 2013 at 11:30 AM, Xinliang David Li davi...@google.com wrote:
On Fri, Nov 8, 2013 at 11:21 AM, Rong Xu x...@google.com wrote:
On Fri, Nov 8, 2013 at 11:02 AM, Xinliang David Li davi...@google.com
wrote:
On Fri, Nov 8, 2013 at 10:48 AM, Rong Xu x...@google.com wrote:
On Fri
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 x...@google.com wrote:
Honza, Thanks for the comments!
Attached
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
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 x...@google.com
* contrib/profile_tool (ModuleInfo): write out ggc_memory to gcda file.
* gcc/gcov-io.c (gcov_read_module_info
seems fine to me for google branches.
-Rong
On Tue, Oct 22, 2013 at 10:51 AM, Dehao Chen de...@google.com 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
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 x...@google.com
* cp/semantics.c (finish_compound_literal): Put
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
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 x...@google.com
* predict.c (tree_predict_by_opcode): Bump
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 davi...@google.com wrote:
Why this 'percent += 4' instead of taking the max?
David
On Fri, Oct 11, 2013 at 2:10 PM, Rong Xu x
ok. that makes sense.
On Fri, Oct 11, 2013 at 2:41 PM, Xinliang David Li davi...@google.com wrote:
Should it be max + some_delta then?
David
On Fri, Oct 11, 2013 at 2:32 PM, Rong Xu x...@google.com wrote:
I want to differentiate the cases w/o and w/ builtin.
If I take the max
;
+ break;
+}
+}
+}
+}
+ predict_edge (then_edge, PRED_BUILTIN_EXPECT, hitrate);
}
/* Try pointer heuristic.
A comparison ptr == 0 is predicted as false.
On Fri, Oct 11, 2013 at 2:45 PM, Rong Xu x...@google.com wrote:
ok
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 x...@google.com wrote:
Hi,
An earlier patch (r203167) changed the default probability for
builtin_expect to 90%.
It does not work properly for the following case
Radhakrishnan ramra...@arm.com 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 hubi...@ucw.cz wrote:
Thanks for the suggestion. This is much cleaner than to use binary
parameter.
Just
On Wed, Oct 2, 2013 at 9:08 AM, Jan Hubicka hubi...@ucw.cz 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 the branch
attached the new patch. OK for check in?
On Wed, Oct 2, 2013 at 9:12 AM, Jan Hubicka hubi...@ucw.cz 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
Here is the new patch. Honaz: Could you take a look?
Thanks,
-Rong
On Wed, Oct 2, 2013 at 2:31 PM, Jan Hubicka hubi...@ucw.cz 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
ping.
On Fri, Sep 27, 2013 at 3:56 PM, Rong Xu x...@google.com 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
is: for w/ and w/o
ping.
On Fri, Sep 27, 2013 at 3:53 PM, Rong Xu x...@google.com 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 the branch
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
2013-09-26 Rong Xu x...@google.com
* ipa-inline-analysis.c (estimate_function_body_sizes
builtin_expect, we have different size/time estimation
for early inlining.
This patch fixes this problem.
-Rong
2013-09-26 Rong Xu x...@google.com
* ipa-inline-analysis.c (estimate_function_body_sizes): fix
the size estimation for builtin_expect.
This seems fine
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,
for
builtin_expert
to 90%. With the alternate hirate, we measured performance
improvement for google
benchmarks and Linux kernel.
-Rong
2013-09-26 Rong Xu x...@google.com
* params.def (DEFPARAM): New
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
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
On Tue, Sep 24, 2013 at 5:31 AM, Jan Hubicka hubi...@ucw.cz 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
.
This patch fixes this problem.
-Rong
2013-09-26 Rong Xu x...@google.com
* ipa-inline-analysis.c (estimate_function_body_sizes): fix
the size estimation for builtin_expect.
Index: ipa-inline-analysis.c
===
--- ipa
2013-09-26 Rong Xu x...@google.com
* params.def (DEFPARAM): New.
* params.def: New.
* predict.c (tree_predict_by_opcode): Alternate
probablity hirate for builtin_expect.
Index: params.def
On Thu, Sep 26, 2013 at 2:54 PM, Jan Hubicka hubi...@ucw.cz 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
On Fri, Aug 30, 2013 at 7:50 AM, Teresa Johnson tejohn...@google.com 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.
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
===
---
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 davi...@google.com wrote:
I
, Xinliang David Li davi...@google.com 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 x...@google.com wrote:
We have seen the issue before. It does fail the profile boostrap as it
reads a wrong gcda file.
I
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 x...@google.com
1 - 100 of 169 matches
Mail list logo
