Re: a new libgcov interface: __gcov_dump_all

2014-07-22 Thread Xinliang David Li
Please take a look the updated patch. It addresses the issue of using dlclose before dump, and potential races (between a thread closing a library and the dumper call). David On Sun, Jul 20, 2014 at 11:12 PM, Nathan Sidwell nat...@acm.org wrote: On 07/20/14 21:38, Xinliang David Li wrote

Re: a new libgcov interface: __gcov_dump_all

2014-07-20 Thread Xinliang David Li
with shared libs. David On Sun, Jul 20, 2014 at 12:42 PM, Nathan Sidwell nat...@acm.org wrote: On 07/18/14 22:41, Xinliang David Li wrote: Hi, the following patch implements a new dumper interface to allow dumping of profile data for all instrumented shared libraries. For good reasons, existing

Re: FDO and source changes

2014-07-18 Thread Xinliang David Li
Any other concern of the patch? I don't really like the name of the parameter myself. Do you have better suggestions? thanks, David On Thu, Jul 17, 2014 at 10:17 AM, Xinliang David Li davi...@google.com wrote: I see why you do not like first_global_object_name because changing it would

a new libgcov interface: __gcov_dump_all

2014-07-18 Thread Xinliang David Li
=== --- libgcc/ChangeLog(revision 212682) +++ libgcc/ChangeLog(working copy) @@ -1,3 +1,9 @@ +2014-07-18 Xinliang David Li davi...@google.com + + * libgcov-driver.c: Force __gcov_dump to be exported + * libgcov-interface.c

Re: FDO and source changes

2014-07-17 Thread Xinliang David Li
On Wed, Jul 16, 2014 at 4:42 PM, Jan Hubicka hubi...@ucw.cz wrote: Instrumentation based FDO is designed to work when the source files that are used to generate the instr binary match exactly with the sources in profile-use compile. It is known historically that using stale profile (due to

Re: FDO and source changes

2014-07-17 Thread Xinliang David Li
I see why you do not like first_global_object_name because changing it would cause all functions from that unit to drop the profiles. Perhaps we can combine function name and compilation unit (gcov file) name? that is a good idea -- it will also solve the LTO problem you mentioned above.

FDO and source changes

2014-07-16 Thread Xinliang David Li
blocks. */ DEFPARAM (PARAM_SLP_MAX_INSNS_IN_BB, slp-max-insns-in-bb, Index: ChangeLog === --- ChangeLog (revision 212682) +++ ChangeLog (working copy) @@ -1,3 +1,10 @@ +2014-07-16 Xinliang David Li davi...@google.com

Re: [GOOGLE] Rewrite FUNCTION_DECL references after LIPO linking

2014-07-15 Thread Xinliang David Li
ok. This is now consistent with how cgraph targets are handled. (Changes like this may shake up more bugs due to bad assumptions. More extensive testing after this is expected). David On Tue, Jul 15, 2014 at 3:24 AM, Teresa Johnson tejohn...@google.com wrote: This patch will rewrite references

Re: [GOOGLE] replace getline with fgets

2014-07-14 Thread Xinliang David Li
On Mon, Jul 14, 2014 at 2:37 PM, Andrew Pinski pins...@gmail.com wrote: On Mon, Jul 14, 2014 at 1:40 PM, Dehao Chen de...@google.com wrote: This patch replaces getline with fgets so that gcc builts fine in darwin. Why not add getline to libiberty instead? This patch causes a huge stack

Re: [PATCH] offline gcda profile processing tool

2014-07-11 Thread Xinliang David Li
I wonder why. The struct definition for gcov_fn_info has not changed in this patch. David On Fri, Jul 11, 2014 at 1:07 AM, 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

Re: [PATCH] offline gcda profile processing tool

2014-07-11 Thread Xinliang David Li
What is the macro to test POSIX IO on host? The guard uses TARGET_POSIX_IO which 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

Re: [PATCH] offline gcda profile processing tool

2014-07-11 Thread Xinliang David Li
it as it is (if not doing memcpy for the whole array). David On Fri, Jul 11, 2014 at 8:44 AM, Jakub Jelinek ja...@redhat.com wrote: On Fri, Jul 11, 2014 at 08:42:27AM -0700, Xinliang David Li wrote: I wonder why. The struct definition for gcov_fn_info has not changed in this patch. Perhaps it has been used

Re: [PATCH] Support addsub/subadd as non-isomorphic operations for SLP vectorizer.

2014-07-08 Thread Xinliang David Li
Cong, can you ping this patch again? There does not seem to be pending comments left. David On Tue, Dec 17, 2013 at 10:05 AM, Cong Hou co...@google.com wrote: Ping? thanks, Cong On Mon, Dec 2, 2013 at 5:02 PM, Cong Hou co...@google.com wrote: Any comment on this patch? thanks, Cong

Re: [PATCH] C++ thunk section names

2014-07-07 Thread Xinliang David Li
Sri, can you provide examples to show why putting thunks into the same section as the target function when function reorder is on can be bad ? Thanks, David On Thu, Jun 26, 2014 at 10:29 AM, Sriraman Tallam tmsri...@google.com wrote: Hi Honza, Could you review this patch when you find

Re: [GOOGLE] Define libgcov interface for distinguishing -ftest-coverage from -fprofile-generate

2014-07-02 Thread Xinliang David Li
Should the interface be something like: int __gcov_profiling_for_test_coverage(void)? David On Wed, Jul 2, 2014 at 12:55 PM, Teresa Johnson tejohn...@google.com wrote: The following patch adds support for a new libgcov interface, __gcov_profiling_enabled, that can be used by applications to

Re: [GOOGLE] Define libgcov interface for distinguishing -ftest-coverage from -fprofile-generate

2014-07-02 Thread Xinliang David Li
David Li davi...@google.com wrote: Should the interface be something like: int __gcov_profiling_for_test_coverage(void)? I was equating the term profiling with -fprofile-generate, as opposed to -ftest-coverage instrumentation. But I can change it to this if you think that is clearer. Teresa

Re: [GOOGLE] Define libgcov interface for distinguishing -ftest-coverage from -fprofile-generate

2014-07-02 Thread Xinliang David Li
-generate). */ + +unsigned int __gcov_profiling_for_test_coverage (void) +{ + return __gcov_test_coverage; +} + #endif /* L_gcov_dump */ #ifdef L_gcov_sampling On Wed, Jul 2, 2014 at 1:25 PM, Xinliang David Li davi...@google.com wrote: The reason is that test coverage is using

Re: [GOOGLE] LIPO resolved node handling for inline clone references

2014-07-01 Thread Xinliang David Li
Ok, with minor fix to the comments: 1) Before possibly cloning -- Before possibly creating a new 2) It is not clear from the comments that the remaining references are from call statements in ipa cp clones that have not been fixed up. Possibly add a 3 line example to show the call statements

Re: [GOOGLE] Report the difference between profiled and guessed or annotated branch probabilities.

2014-07-01 Thread Xinliang David Li
when appropriate. * common.opt (fcheck-branch-annotation) (fcheck-branch-annotation-threshold=): Add an extra GCC option to turn on report On Fri, Jun 27, 2014 at 3:20 PM, Xinliang David Li davi...@google.com wrote: Hi Yi, 1) please add comments before new functions

Re: [GOOGLE] Report the difference between profiled and guessed or annotated branch probabilities.

2014-06-27 Thread Xinliang David Li
Hi Yi, 1) please add comments before new functions as documentation -- follow the coding style guideline 2) missing documenation on the new flags (pointed out by Gerald) 3) Please refactor the check code in afdo_calculate_branch_prob into a helper function 4) the change log is not needed for

Re: [Google/4_8] Support for embedding build info into gcda files

2014-05-23 Thread Xinliang David Li
The change makes gcov_info a variable length array, which is not ideal. Better just add one more field (instead of two): struct gcov_info { ... char ** build_info; }; For regular case, it is null, for case where the build info is available, make it point to a string array (with an null end

Re: [Google/4_8] Support for embedding build info into gcda files

2014-05-23 Thread Xinliang David Li
On Fri, May 23, 2014 at 1:59 PM, Teresa Johnson tejohn...@google.com wrote: Done. Passes manual testing, rerunning regression testing. New patch attached. Thanks, Teresa On Fri, May 23, 2014 at 11:35 AM, Xinliang David Li davi...@google.com wrote: The change makes gcov_info a variable length

Re: [Google/4_8] Support for embedding build info into gcda files

2014-05-23 Thread Xinliang David Li
On Fri, May 23, 2014 at 2:50 PM, Teresa Johnson tejohn...@google.com wrote: On Fri, May 23, 2014 at 2:28 PM, Xinliang David Li davi...@google.com wrote: for (i = 0; i num_strings; i++) +{ + if (strcmp (build_info_strings[i], gi_ptr-build_info[i])) Add also check

Re: [GOOGLE] get resolved node in walk_polymorphic_call_targets

2014-05-23 Thread Xinliang David Li
ok. David On Fri, May 23, 2014 at 3:03 PM, Dehao Chen de...@google.com wrote: This patch fixes LIPO ICE that an unresolved node escaped after lipo fixup. testing on going. OK for google-4_9? Thanks, Dehao Index: gcc/ipa.c

Re: [Google/4_8] Support for embedding build info into gcda files

2014-05-23 Thread Xinliang David Li
ok On Fri, May 23, 2014 at 3:14 PM, Teresa Johnson tejohn...@google.com wrote: On May 23, 2014 2:56 PM, Xinliang David Li davi...@google.com wrote: On Fri, May 23, 2014 at 2:50 PM, Teresa Johnson tejohn...@google.com wrote: On Fri, May 23, 2014 at 2:28 PM, Xinliang David Li davi

Fix broken graph dump

2014-05-23 Thread Xinliang David Li
=== --- ChangeLog (revision 210881) +++ ChangeLog (working copy) @@ -1,3 +1,9 @@ +2014-05-23 Xinliang David Li davi...@google.com + + * tree-pretty-print.c (dump_function_header): Print cgraph uid. + * passes.c (pass_init_dump_file

Re: [google gcc-4_8][x86_64]Optimize access to globals in -fpie -pie builds with copy relocations

2014-05-22 Thread Xinliang David Li
Also missing documentation in invoke.texi? Other than that, ok. David On Thu, May 22, 2014 at 5:00 PM, Paul Pluzhnikov ppluzhni...@google.com wrote: On Thu, May 22, 2014 at 4:36 PM, Sriraman Tallam tmsri...@google.com wrote: This patch is pending review for trunk. Please see if this is ok to

Re: [PATCH, AArch64] Fix for PR61202

2014-05-21 Thread Xinliang David Li
Since it is in trunk and gcc-4_9-branch, there is no need to put into google branches -- will get it automatically after next merge. David On Wed, May 21, 2014 at 8:13 PM, Carrot Wei car...@google.com wrote: Committed to trunk, 4.9, and waiting for the release of 4.8.3. OK for google/main and

Re: [Google/4_8] LIPO COMDAT profile fixups

2014-05-20 Thread Xinliang David Li
Why duplicating the merger functions in dyn-ipa.c? Should those in libgcov-merge.c be reused? The refactoring of gcov_exit_write_gcda should probably be done in a separate patch -- preferably submitted to trunk too. David On Mon, May 19, 2014 at 10:08 PM, Teresa Johnson tejohn...@google.com

Re: [Google/4_8] LIPO COMDAT profile fixups

2014-05-20 Thread Xinliang David Li
On Tue, May 20, 2014 at 6:32 AM, Teresa Johnson tejohn...@google.com wrote: On Mon, May 19, 2014 at 11:51 PM, Xinliang David Li davi...@google.com wrote: Why duplicating the merger functions in dyn-ipa.c? Should those in libgcov-merge.c be reused? The merger functions in libgcov-merge.c use

Re: add dbgcnt and opt-info support for devirtualization

2014-05-20 Thread Xinliang David Li
On Tue, May 20, 2014 at 4:32 AM, Richard Biener richard.guent...@gmail.com wrote: On Mon, May 19, 2014 at 5:24 PM, Xinliang David Li davi...@google.com wrote: Sorry about it. Here is the patch. There is one remaining case where cgraph_dump_file and dump_enable_p are checked separately

Re: add dbgcnt and opt-info support for devirtualization

2014-05-19 Thread Xinliang David Li
, 2014 at 11:19 PM, Xinliang David Li davi...@google.com wrote: Modified the patch according to yours and Richard's feedback. PTAL. ENOPATCH. Btw, I don't see any issue with leaking node order to opt-report. Richard. thanks, David On Fri, May 16, 2014 at 9:03 AM, Jan Hubicka hubi

Re: add dbgcnt and opt-info support for devirtualization

2014-05-18 Thread Xinliang David Li
There is no test regression. Ok with this patch? David On Fri, May 16, 2014 at 2:19 PM, Xinliang David Li davi...@google.com wrote: Modified the patch according to yours and Richard's feedback. PTAL. thanks, David On Fri, May 16, 2014 at 9:03 AM, Jan Hubicka hubi...@ucw.cz wrote: Hi

Re: Add a new test

2014-05-18 Thread Xinliang David Li
Ok to check in the test? David On Fri, May 16, 2014 at 4:58 PM, Xinliang David Li davi...@google.com wrote: This test makes sure compiler does not wrongly devirtualize virtual calls into __cxa_pure_virtual or __buitlin_unreachable. Ok to checkin? David

Re: add dbgcnt and opt-info support for devirtualization

2014-05-16 Thread Xinliang David Li
On Fri, May 16, 2014 at 4:00 AM, Richard Biener richard.guent...@gmail.com wrote: On Fri, May 16, 2014 at 1:54 AM, Xinliang David Li davi...@google.com wrote: Hi, debugging runtime bugs due to devirtualization can be hard for very large C++ programs with complicated class hierarchy. This patch

Re: add dbgcnt and opt-info support for devirtualization

2014-05-16 Thread Xinliang David Li
) @@ -1,3 +1,18 @@ +2014-05-15 Xinliang David Li davi...@google.com + + * cgraphunit.c (walk_polymorphic_call_targets): Add + dbgcnt and fopt-info support. + 2014-05-15 Xinliang David Li davi...@google.com + + * cgraphunit.c (walk_polymorphic_call_targets): Add

Re: add dbgcnt and opt-info support for devirtualization

2014-05-16 Thread Xinliang David Li
On Fri, May 16, 2014 at 9:51 AM, Jan Hubicka hubi...@ucw.cz wrote: I have been chasing a runtime failure of a very large test built with gcc-4_9. The bad code either calls a pure function or turn a virtual call into __builtin_unreachable (incomplete target set). The indirect info shows the

Re: add dbgcnt and opt-info support for devirtualization

2014-05-16 Thread Xinliang David Li
=== --- ChangeLog (revision 210479) +++ ChangeLog (working copy) @@ -1,3 +1,18 @@ +2014-05-15 Xinliang David Li davi...@google.com + + * cgraphunit.c (walk_polymorphic_call_targets): Add + dbgcnt and fopt-info support. + 2014-05-15 Xinliang David Li davi

Add a new test

2014-05-16 Thread Xinliang David Li
/ChangeLog (working copy) @@ -1,3 +1,7 @@ +2014-05-16 Xinliang David Li davi...@google.com + + * g++.dg/ipa/devirt-33.C: New testcase. + 2014-05-15 Martin Jambor mjam...@suse.cz PR ipa/61085 Index: testsuite/g++.dg/ipa/devirt-33.C

add dbgcnt and opt-info support for devirtualization

2014-05-15 Thread Xinliang David Li
for trunk after build and test? thanks, David Index: ChangeLog === --- ChangeLog (revision 210479) +++ ChangeLog (working copy) @@ -1,3 +1,18 @@ +2014-05-15 Xinliang David Li davi...@google.com + + * cgraphunit.c

Re: [PATCH] Add missing -fdump-* options

2014-05-13 Thread Xinliang David Li
On Tue, May 13, 2014 at 1:39 AM, Richard Biener richard.guent...@gmail.com wrote: On Fri, May 9, 2014 at 5:54 PM, Teresa Johnson tejohn...@google.com wrote: I discovered that the support for the documented -fdump-* options optimized, missed, note and optall was missing. Added that and fixed a

Re: [PATCH] Fix issue in uninit analysis (PR middle-end/61112)

2014-05-13 Thread Xinliang David Li
I have concerns with the proposed this patch: 1) not sharing cd_root may lead to difficulties in later predication simplication 2) the change to check post-dom may also lead to incomplete predicate chain. I think the right fix to the problem is to realize that BBs with the following conditions

Re: [PATCH] Fix issue in uninit analysis (PR middle-end/61112)

2014-05-13 Thread Xinliang David Li
I think the right fix to the problem is to realize that BBs with the following conditions y_8 !=0, p.0_10 !=0, and x_5 !=0 are actually control equivalent. This fact allows simplifying the USE predicates from (y_8 !=0 OR p.0_10 !=0 OR x_5 !=0) into just p.0_10 !=0 which is the same as the

Re: [google gcc-4_8] LIPO: check the incompatibility of use and saved command line

2014-05-12 Thread Xinliang David Li
Ok. For non-autofdo path, I think a warning (even an error) is needed in case of mismatch. David On Mon, May 12, 2014 at 4:35 PM, Rong Xu x...@google.com wrote: Hi, This patch adds an extra check of the incompatibility of use and saved command line for the primary module. If the check files,

Re: [Google/4-8] Support for user-guided feedback-directed library optimization

2014-05-11 Thread Xinliang David Li
=== --- gcc/builtins.c(revision 210019) +++ gcc/builtins.c(working copy) @@ -87,6 +87,9 @@ static rtx result_vector (int, rtx); #endif static void expand_builtin_update_setjmp_buf (rtx); static void

Re: [google gcc-4_8] fix lipo ICE

2014-05-08 Thread Xinliang David Li
ok. David On Thu, May 8, 2014 at 1:33 PM, Rong Xu x...@google.com wrote: 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

Re: [PATCH] AutoFDO patch for trunk

2014-05-07 Thread Xinliang David Li
Have you announced the autofdo profile tool to gcc list? David On Wed, May 7, 2014 at 2:24 PM, Dehao Chen de...@google.com wrote: Hi, I'm planning to port the AutoFDO patch upstream. Attached is the prepared patch. You can also find the patch in http://codereview.appspot.com/99010043 I've

Re: [GOOGLE] handle TYPE_PACK_EXPANSION in lipo_cmp_type

2014-05-05 Thread Xinliang David Li
ok. Also needed in google/gcc-4_9 branch. David On Mon, May 5, 2014 at 8:40 PM, Dehao Chen de...@google.com wrote: This patch handles TYPE_PACK_EXPANSION in lipo_cmp_type. testing on going. OK for google-4_8? Thanks, Dehao Index: gcc/l-ipo.c

Re: Inliner heuristics TLC 1/n - let small function inlinng to ignore cold portion of program

2014-04-23 Thread Xinliang David Li
On Tue, Apr 22, 2014 at 1:17 PM, Jan Hubicka hubi...@ucw.cz 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,

Re: [PATCH, x86] merge movsd/movhpd pair in peephole

2014-04-21 Thread Xinliang David Li
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 amker.ch...@gmail.com wrote: On Thu, Apr 10, 2014 at 8:18 AM, Wei Mi w...@google.com wrote: Hi, For the testcase 1.c #include emmintrin.h double a[1000]; __m128d

Re: LTO inliner -- sensitivity to increasing register pressure

2014-04-18 Thread Xinliang David Li
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

Re: LTO inliner -- sensitivity to increasing register pressure

2014-04-18 Thread Xinliang David Li
On Fri, Apr 18, 2014 at 10:26 AM, Jan Hubicka hubi...@ucw.cz 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,

Re: LTO inliner -- sensitivity to increasing register pressure

2014-04-18 Thread Xinliang David Li
-- any callsite with a net saving will be considered. David Honza Aaron On Fri, 2014-04-18 at 10:36 -0700, Xinliang David Li wrote: 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

Re: LTO inliner -- sensitivity to increasing register pressure

2014-04-18 Thread Xinliang David Li
On Fri, Apr 18, 2014 at 12:51 PM, Jan Hubicka hubi...@ucw.cz 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

Re: LTO inliner -- sensitivity to increasing register pressure

2014-04-18 Thread Xinliang David Li
On Fri, Apr 18, 2014 at 2:16 PM, Jan Hubicka hubi...@ucw.cz wrote: On Fri, Apr 18, 2014 at 12:27 PM, Jan Hubicka hubi...@ucw.cz 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

Re: Inliner heuristics TLC 1/n - let small function inlinng to ignore cold portion of program

2014-04-17 Thread Xinliang David Li
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

Re: [GOOGLE] Fix incorrect detection of recursive calls during LIPO IPA inlining

2014-04-10 Thread Xinliang David Li
Looks good to me. David On Thu, Apr 10, 2014 at 2:04 PM, Teresa Johnson tejohn...@google.com 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

Re: [GOOGLE] AutoFDO+LIPO should invoke add_fake_edge too

2014-04-07 Thread Xinliang David Li
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 de...@google.com wrote: This patch calls add_fake_edge for the AutoFDO+LIPO path. Bootstrapped and passed regression test and performance test. OK for

Re: [GOOGLE] Updates SSA after VPT transofrmations in AFDO pass

2014-04-03 Thread Xinliang David Li
looks fine. David On Thu, Apr 3, 2014 at 10:56 AM, Dehao Chen de...@google.com 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:

Re: [GOOGLE] Refactor the LIPO fixup

2014-03-27 Thread Xinliang David Li
ok. On Thu, Mar 27, 2014 at 9:02 AM, Dehao Chen de...@google.com wrote: On Wed, Mar 26, 2014 at 4:05 PM, Xinliang David Li davi...@google.com 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

Re: [GOOGLE] Refactor the LIPO fixup

2014-03-26 Thread Xinliang David Li
is cgraph_init_gid_map called after linking? David On Wed, Mar 26, 2014 at 3:54 PM, Dehao Chen de...@google.com wrote: Patch updated, passed performance tests. Dehao On Tue, Mar 25, 2014 at 4:03 PM, Xinliang David Li davi...@google.com wrote: Add comment to the new function. init_node_map

Re: [GOOGLE] update ssa before compute_inline_parameters

2014-03-20 Thread Xinliang David Li
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; }

Re: [GOOGLE] update ssa before compute_inline_parameters

2014-03-20 Thread Xinliang David Li
(promoted_stmts); compute_function_frequency (); update_ssa (TODO_update_ssa); Is this update still needed? David On Thu, Mar 20, 2014 at 11:36 AM, Xinliang David Li davi...@google.com wrote: I think the right way to fix this is to wrap the call to early_inliner and check the TODO

Re: [GOOGLE] update ssa before compute_inline_parameters

2014-03-20 Thread Xinliang David Li
The patch is ok. David On Thu, Mar 20, 2014 at 1:10 PM, Dehao Chen de...@google.com wrote: On Thu, Mar 20, 2014 at 1:02 PM, Xinliang David Li davi...@google.com wrote: On Thu, Mar 20, 2014 at 12:40 PM, Dehao Chen de...@google.com wrote: Patch updated to add a wrapper early_inline function

Re: [GOOGLE] Writes annotation info in elf section.

2014-03-12 Thread Xinliang David Li
Why is it not enough to emit warnings during build time when source code changes signifcantly? David On Tue, Mar 11, 2014 at 4:27 PM, Dehao Chen de...@google.com wrote: During AutoFDO annotation, we want to record the annotation stats into an elf section, so that we can calculate how much

Re: [GOOGLE] Writes annotation info in elf section.

2014-03-12 Thread Xinliang David Li
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 davi...@google.com wrote: Why is it not enough to emit warnings during build time when source code changes

Re: [Google] Add libgcov dummy references for weak symbols

2014-03-10 Thread Xinliang David Li
Ok. David On Mon, Mar 10, 2014 at 1:28 PM, Teresa Johnson tejohn...@google.com wrote: This patch adds dummy references to libgcov for the symbols accessed via weak references from application code to ensure they are resolved at link time. Passes regression tests. Ok for google-4_8? Thanks,

Re: [GOOGLE] call compute_inline_parameters before early_inliner

2014-02-26 Thread Xinliang David Li
On Wed, Feb 26, 2014 at 3:23 PM, Dehao Chen de...@google.com wrote: This patch fixes the bug of not calling compute_inline_parameters before early_inliner, which would lead to ICE. Testing on going, OK for google-4_8 if test passes? Thanks, Dehao Index: gcc/auto-profile.c

Re: [GOOGLE] call compute_inline_parameters before early_inliner

2014-02-26 Thread Xinliang David Li
::afdo_annotate_cfg (promoted_stmts); compute_function_frequency (); Dehao On Wed, Feb 26, 2014 at 3:25 PM, Xinliang David Li davi...@google.com wrote: On Wed, Feb 26, 2014 at 3:23 PM, Dehao Chen de...@google.com wrote: This patch fixes the bug of not calling compute_inline_parameters before

Re: [PATCH] Bound number of recursive compute_control_dep_chain calls with a param (PR tree-optimization/56490)

2014-02-21 Thread Xinliang David Li
thanks for the fix! David On Fri, Feb 21, 2014 at 12:21 AM, Jakub Jelinek ja...@redhat.com wrote: Hi! As discussed in the PR, on larger functions we can end up with over 3 million of compute_control_dep_chain nested calls from a single compute_control_dep_chain call, on that testcase all

Re: [google gcc-4_8] not split bb for machine dependent builtins

2014-02-21 Thread Xinliang David Li
Ok. I expect this also submitted to trunk later. David On Fri, Feb 21, 2014 at 2:08 PM, Rong Xu x...@google.com wrote: Hi, For builtins without nothrow attributes, we currently split bb by adding fake edge to func_exit in instrumenting profile counters. While it's safe, The resulted

Re: [PATCH] Handle more COMDAT profiling issues

2014-02-13 Thread Xinliang David Li
On Thu, Feb 13, 2014 at 9:48 AM, Mike Stump mikest...@comcast.net wrote: On Feb 13, 2014, at 8:41 AM, Teresa Johnson tejohn...@google.com wrote: On Wed, Feb 12, 2014 at 2:03 PM, Xinliang David Li davi...@google.com wrote: [ extra lines deleted ] Should non comdat function be skipped? We

Re: [PATCH] Handle more COMDAT profiling issues

2014-02-12 Thread Xinliang David Li
On Wed, Feb 12, 2014 at 8:02 AM, Teresa Johnson tejohn...@google.com wrote: On Wed, Feb 12, 2014 at 6:45 AM, Teresa Johnson tejohn...@google.com wrote: On Tue, Feb 11, 2014 at 6:13 PM, Xinliang David Li davi...@google.com wrote: On Tue, Feb 11, 2014 at 5:36 PM, Teresa Johnson tejohn

Re: [google gcc-4_8] Don't use gcov counter related ssa name as induction variables

2014-02-11 Thread Xinliang David Li
On Mon, Feb 10, 2014 at 11:48 PM, Wei Mi w...@google.com wrote: Here is the updated patch, which follow UD chain to determine whether iv.base is defined by __gcovx.xxx[] var. It is a lot simpler than adding a tree bit. regression test and previously failed benchmark in piii mode is ok. Other

Re: [google gcc-4_8] Don't use gcov counter related ssa name as induction variables

2014-02-11 Thread Xinliang David Li
ok for google branch for now. Please resubmit to trunk and backport the trunk version if needed. thanks, David On Tue, Feb 11, 2014 at 10:29 AM, Wei Mi w...@google.com wrote: +/* Return true if the use is defined by a gcov counter var. + It is used to check if an iv candidate is generated

Re: [PATCH] Handle more COMDAT profiling issues

2014-02-11 Thread Xinliang David Li
Is it better to add some logic in counts_to_freq to determine if the profile count needs to be dropped completely to force profile estimation? David On Mon, Feb 10, 2014 at 2:12 PM, Teresa Johnson tejohn...@google.com wrote: This patch attempts to address the lost profile issue for COMDATs in

Re: [GOOGLE] Emit a single unaligned load/store instruction for i386 m_GENERIC

2014-02-11 Thread Xinliang David Li
ok. David On Tue, Feb 11, 2014 at 4:50 PM, Cong Hou co...@google.com wrote: This small patch lets GCC emit a single unaligned load/store instruction for m_GENERIC i386 CPUs. Bootstrapped and passed regression test. OK for Google branch? thanks, Cong Index: gcc/config/i386/i386.c

Re: [PATCH] Handle more COMDAT profiling issues

2014-02-11 Thread Xinliang David Li
On Tue, Feb 11, 2014 at 5:04 PM, Teresa Johnson tejohn...@google.com wrote: On Tue, Feb 11, 2014 at 2:56 PM, Xinliang David Li davi...@google.com wrote: Is it better to add some logic in counts_to_freq to determine if the profile count needs to be dropped completely to force profile estimation

Re: [GOOGLE] Prevent x_flag_complex_method to be set to 2 for C++.

2014-02-11 Thread Xinliang David Li
ok. David On Tue, Feb 11, 2014 at 5:30 PM, Cong Hou co...@google.com wrote: With this patch x_flag_complex_method won't be set to 2 for C++ so that multiply/divide between std::complex objects won't be replaced by expensive builtin function calls. Bootstrapped and passed regression test.

Re: [PATCH] Handle more COMDAT profiling issues

2014-02-11 Thread Xinliang David Li
On Tue, Feb 11, 2014 at 5:36 PM, Teresa Johnson tejohn...@google.com wrote: On Tue, Feb 11, 2014 at 5:16 PM, Xinliang David Li davi...@google.com wrote: Why is call graph needed to determine whether to drop the profile? Because we detect this situation by looking for cases where the call edge

Re: [google gcc-4_8] Don't use gcov counter related ssa name as induction variables

2014-02-10 Thread Xinliang David Li
I don't think you should add a new tree bit just for this. A simple UD check can determine prephitmp_23, etc are abnormal ssa names: # prephitmp_23 = PHI PROF_edge_counter_10(5), pretmp_1(3) PROF_edge_counter_10 = prephitmp_23 + 1; __gcov0.foo[0] = PROF_edge_counter_10; Note you may need

Re: minor help message fix

2014-02-07 Thread Xinliang David Li
On Fri, Feb 7, 2014 at 1:22 AM, Richard Biener richard.guent...@gmail.com wrote: On Thu, Feb 6, 2014 at 10:30 PM, Xinliang David Li davi...@google.com wrote: Hi the following patch removes the 'state' print for -ftree-tree-vectorize option which does not make sense anymore. Ok for trunk? Hmm

minor help message fix

2014-02-06 Thread Xinliang David Li
) @@ -1,3 +1,7 @@ +2014-02-06 Xinliang David Li davi...@google.com + + * opts.c (print_filtered_help): Fix help message bug. + 2014-02-06 Kyrylo Tkachov kyrylo.tkac...@arm.com * config/arm/aarch-cost-tables.h (cortexa57_extra_costs): New table. Index: opts.c

Re: [google gcc-4_8] fix profiledbootstrap

2014-02-04 Thread Xinliang David Li
ok. David On Tue, Feb 4, 2014 at 11:28 AM, Rong Xu x...@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

Re: [google gcc-4_8] gcov-tool: some new LIPO supports.

2014-01-30 Thread Xinliang David Li
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 profile for reuse, debug or performance tuning purpose. -l, --modu_list file Only use the modules in this file I think in verbose

Re: [GOOGLE] Adjust profile for AutoFDO

2014-01-27 Thread Xinliang David Li
Ok. For future cleanup, It will be better to define a new helper function is_profile_missing_p (cfun) -- which checks entry count for instrumentation based FDO, and something else for autofdo. David On Fri, Jan 24, 2014 at 9:28 PM, Dehao Chen de...@google.com wrote: This patch fixes

Re: [google gcc-4_8] Tree Loop Unrolling - Relax code size increase with -O2

2014-01-27 Thread Xinliang David Li
patterns with one exception, pr53265.c. Loop unrolling exposed the array out of bounds access which is now caught. Ok to commit? Thanks Sri On Tue, Jan 21, 2014 at 4:51 PM, Xinliang David Li davi...@google.com wrote: ok. David On Tue, Jan 21, 2014 at 4:46 PM, Sriraman Tallam tmsri

Re: [GOOGLE] Builtins handling in IVOPT

2014-01-23 Thread Xinliang David Li
for AVG_LOOP_ITER. Both patches are attached. Thanks, Wei. On Wed, Jan 22, 2014 at 4:42 PM, Xinliang David Li davi...@google.com wrote: On Wed, Jan 22, 2014 at 2:23 PM, Wei Mi w...@google.com wrote: This patch handles the mem access builtins in ivopt. The original problem described here

Re: [Google gcc-4_8] always emit __gcov_get_profile_prefix when linking libgcov.a

2014-01-23 Thread Xinliang David Li
ok. David On Thu, Jan 23, 2014 at 4:21 PM, Rong Xu x...@google.com wrote: 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):

Re: [PATCH] Set correct probability for ORDER/UNORDER jumps

2014-01-23 Thread Xinliang David Li
Is it possible to add a test case? David On Wed, Jan 22, 2014 at 6:08 PM, Dehao Chen de...@google.com wrote: During floating point comparison, compiler inserts conditional jumps to check if the operand is NAN. These type of checks are normally false. However, compiler sets the probability the

Re: [GOOGLE] Restrict the count_scale to be no larger than 100%

2014-01-22 Thread Xinliang David Li
not necessary. We only need the first part (tree-inline.c). Thanks, Dehao On Fri, Jan 17, 2014 at 3:12 PM, Xinliang David Li davi...@google.com wrote: Can callgraph node count be fixed up properly instead of doing individual fixups like this? David On Fri, Jan 17, 2014 at 2:38 PM, Dehao

Re: [GOOGLE] Builtins handling in IVOPT

2014-01-22 Thread Xinliang David Li
On Wed, Jan 22, 2014 at 2:23 PM, Wei Mi w...@google.com wrote: This patch handles the mem access builtins in ivopt. The original problem described here: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02648.html Bootstrapped and passed regression test. Performance test ok for plain, fdo and

Re: [google gcc-4_8] Tree Loop Unrolling - Relax code size increase with -O2

2014-01-21 Thread Xinliang David Li
I think it might be better to introduce a new parameter for max peel insn at O2 (e.g, call it MAX_O2_COMPLETELY_PEEL_INSN or MAX_DEFAULT_...), and use the same logic in your patch to override the MAX_COMPLETELY_PEELED_INSN parameter at O2). By so doing, we don't need to have a hard coded factor

Re: [google gcc-4_8] Tree Loop Unrolling - Relax code size increase with -O2

2014-01-21 Thread Xinliang David Li
ok. David On Tue, Jan 21, 2014 at 4:46 PM, Sriraman Tallam tmsri...@google.com wrote: On Tue, Jan 21, 2014 at 2:49 PM, Xinliang David Li davi...@google.com wrote: I think it might be better to introduce a new parameter for max peel insn at O2 (e.g, call it MAX_O2_COMPLETELY_PEEL_INSN

Re: [GOOGLE] don't overwrite precomputed loop bound in AutoFDO

2014-01-17 Thread Xinliang David Li
Ok. David On Fri, Jan 17, 2014 at 9:08 AM, Dehao Chen de...@google.com wrote: If a loop is cunrolled/vectorized, the AutoFDO computed trip count will be very small. This patch disallows overwritting of precomputed loop bound in AutoFDO mode. Bootstrapped and passed regression test.

Re: [google gcc-4_8] port gcov-tool to gcc-4_8

2014-01-17 Thread Xinliang David Li
For LIPO parameters, you can do this 1) isolate all LIPO specific parameters into lipo_params.def, and include it from params.def. 2) include lipo_params.def (after proper definition of DEFPARAM) in the profile tool source dir. By so doing, the compiler setting and profile tool will be in sync.

Re: [google gcc-4_8] port gcov-tool to gcc-4_8

2014-01-17 Thread Xinliang David Li
and let logic in dyn-ipa.c takes care of the rest. Please find the update patch which reads the default values from params.def. -Rong On Fri, Jan 17, 2014 at 12:05 PM, Xinliang David Li davi...@google.com wrote: For LIPO parameters, you can do this 1) isolate all LIPO specific parameters

Re: [GOOGLE] Restrict the count_scale to be no larger than 100%

2014-01-17 Thread Xinliang David Li
Can callgraph node count be fixed up properly instead of doing individual fixups like this? David On Fri, Jan 17, 2014 at 2:38 PM, Dehao Chen de...@google.com wrote: In AutoFDO, sometime edge count might be propagated to be too large due to bad debug info. In this cases, we need to make sure

Re: [GOOGLE] Handle integer overflow in unroller code size limit computation

2014-01-15 Thread Xinliang David Li
ok. David On Wed, Jan 15, 2014 at 9:10 AM, Teresa Johnson tejohn...@google.com wrote: Regression tested, ok for google/4_8? Thanks, Teresa 2014-01-15 Teresa Johnson tejohn...@google.com * loop-unroll.c (code_size_limit_factor): Handle int overflow. Index: loop-unroll.c

Re: [google gcc-4_8] backport libgcov re-factoring patches from trunk

2014-01-15 Thread Xinliang David Li
In libgcov-driver.c, 1) there are couple of places with trailing white spaces (e.g, in gcov_sort_n_vals body), please remove 2) gcov_exit_write_gcda in trunk takes eof_pos as an arg, and check it before writing the header. I think this is more correct than in your patch 3) It would be better to

<    1   2   3   4   5   6   7   8   9   10   >