OK for google-4_8 and google-4_9
Thanks,
Dehao
On Tue, Jun 24, 2014 at 3:09 PM, Yi Yang ahyan...@google.com wrote:
Hi,
This patch removes unnecessary edge probability calculations in
afdo_propagate_circuit() that would eventually be overridden by
afdo_calculate_branch_prob().
This would
You don't need extra space to store file name in locus_information_t.
Use pointer instead.
Dehao
On Mon, Jun 30, 2014 at 1:36 PM, Yi Yang ahyan...@google.com wrote:
I refactored the code and added comments. A bug (prematurely breaking
from a loop) was fixed during the refactoring.
(My last
Let's use %d to replace %f (manual conversion, let's do xx%).
Dehao
On Mon, Jun 30, 2014 at 2:06 PM, Yi Yang ahyan...@google.com wrote:
Fixed.
Also, I spotted some warnings caused by me using %lfs in snprintf().
I changed these to %f and tested.
On Mon, Jun 30, 2014 at 1:49 PM, Dehao Chen
that for the actual probability, the best way to store it is to
store the edge count, since the probability is just
edge_count/bb_count. But this causes disparity in the formats of the
two probabilities.
On Mon, Jun 30, 2014 at 2:12 PM, Dehao Chen de...@google.com wrote:
Let's use %d to replace %f
wrote:
Done.
On Mon, Jun 30, 2014 at 5:20 PM, Dehao Chen de...@google.com wrote:
For get_locus_information, can you cal get_inline_stack and directly use
its
output to get the function name instead?
Dehao
On Mon, Jun 30, 2014 at 4:47 PM, Yi Yang ahyan...@google.com wrote:
Removed
This patch replaces getline with fgets so that gcc builts fine in darwin.
Testing on going, ok for google-4_9 if test passes?
Thanks,
Dehao
Index: gcc/coverage.c
===
--- gcc/coverage.c (revision 212523)
+++ gcc/coverage.c (working
In AutoFDO, we increase einline iterations. This could lead to
extensive code bloat if we have recursive calls like:
dtor() {
destroy(node);
}
destroy(node) {
destroy(left)
destroy(right)
}
In this case, the size growth will be around 8 which is smaller than
threshold (11). However, if we
at 2:25 PM, Dehao Chen de...@google.com wrote:
In AutoFDO, we increase einline iterations. This could lead to
extensive code bloat if we have recursive calls like:
dtor() {
destroy(node);
}
destroy(node) {
destroy(left)
destroy(right)
}
In this case, the size growth will be around 8
We do not do sophisticated recursive call detection in einline phase.
It only happens in ipa-inline phase.
Dehao
On Thu, Nov 13, 2014 at 3:18 PM, Xinliang David Li davi...@google.com wrote:
On Thu, Nov 13, 2014 at 2:57 PM, Dehao Chen de...@google.com wrote:
IIRC, AutoFDO the actual iteration
(callee-decl)
+ else if (!flag_auto_profile DECL_COMDAT (callee-decl)
growth = PARAM_VALUE (PARAM_EARLY_INLINING_INSNS_COMDAT))
;
else if ((n = num_calls (callee)) != 0
On Thu, Nov 13, 2014 at 3:42 PM, Dehao Chen de...@google.com wrote:
We do not do sophisticated
.
Is the workaround needed for the mainline autofdo version too?
-Andi
David
On Mon, Nov 17, 2014 at 12:47 PM, Dehao Chen de...@google.com wrote:
The patch was updated to ignore comdat einline tuning for AutoFDO.
Performance testing is green.
This patch updates ssa and inline summary in the correct location for AutoFDO.
Bootstrapped and passed regression test. OK for trunk?
Thanks,
Dehao
gcc/ChangeLog:
2014-11-18 Dehao Chen de...@google.com
* auto-profile.c (afdo_annotate_cfg): Invoke update_ssa in the right
place
/auto-profile.c (revision 0)
@@ -0,0 +1,1662 @@
+/* Read and annotate call graph profile from the auto profile data file.
+ Copyright (C) 2014. Free Software Foundation, Inc.
+ Contributed by Dehao Chen (de...@google.com)
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute
This will cause bzip2 performance to degrade 6%. I haven't had time to
triage the problem. Will investigate this later.
Still I would preffer to make this by default
flag_reorder_blocks_and_partition
to false with auto_profile. We could do that incrementally, lets just drop
this from
===
--- gcc/auto-profile.c (revision 0)
+++ gcc/auto-profile.c (revision 0)
@@ -0,0 +1,1664 @@
+/* Read and annotate call graph profile from the auto profile data file.
+ Copyright (C) 2014. Free Software Foundation, Inc.
+ Contributed by Dehao Chen (de...@google.com)
+
+This file is part
The new patch is attached. I used clang-format for format auto-profile.{c|h}
Thanks,
Dehao
On Tue, Oct 14, 2014 at 2:05 PM, Dehao Chen de...@google.com wrote:
On Tue, Oct 14, 2014 at 8:02 AM, Jan Hubicka hubi...@ucw.cz wrote:
Index: gcc/cgraphclones.c
This patch recalculates dominance info before update_ssa call in
AutoFDO. This fixes bug when dominance info is out-of-date and causes
segfaults during update_ssa.
Bootstrapped and regression test on-going.
OK for google-4_9 branch?
Thanks,
Dehao
Index: gcc/auto-profile.c
...@google.com wrote:
Is it destroyed by value profile transformations? Can you move the
dominance recomputing code closer to where it gets invalidated?
David
On Wed, Oct 15, 2014 at 10:37 AM, Dehao Chen de...@google.com wrote:
This patch recalculates dominance info before update_ssa call
and annotate call graph profile from the auto profile data file.
+ Copyright (C) 2014. Free Software Foundation, Inc.
+ Contributed by Dehao Chen (de...@google.com)
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General
. Free Software Foundation, Inc.
+ Contributed by Dehao Chen (de...@google.com)
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3
This patch refactors LIPO fixup related code to move it into a
standalone function. This makes sure that
symtab_remove_unreachable_nodes is called right after the fixup so
that there is not dangling cgraph nodes any time.
Bootstrapped and regression test on-going.
OK for google-4_8?
Thanks,
:
2014-03-21 Dehao Chen de...@google.com
*ipa-inline.c (early_inliner): updates overall summary.
Looks resonable, do you have testcase where it would make a difference?
Sorry, no small test case because this depends on autofdo profile.
The problem actually does not manifest in trunk unless
.
David
On Tue, Mar 25, 2014 at 3:38 PM, Dehao Chen de...@google.com wrote:
This patch refactors LIPO fixup related code to move it into a
standalone function. This makes sure that
symtab_remove_unreachable_nodes is called right after the fixup so
that there is not dangling cgraph nodes any time
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 is better invoked after
the link step to avoid
This patch updates SSA after VPT transformation. This is needed
because compute_inline_parameters will ICE without updated SSA.
Testing on-going.
OK for google-4_8?
Thanks,
Dehao
Index: gcc/auto-profile.c
===
---
This patch calls add_fake_edge for the AutoFDO+LIPO path.
Bootstrapped and passed regression test and performance test.
OK for google-4_8?
Thanks,
Dehao
Index: gcc/auto-profile.c
===
--- gcc/auto-profile.c (revision 209123)
+++
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
===
--- gcc/l-ipo.c (revision 209226)
+++ gcc/l-ipo.c (working copy)
@@ -676,6 +676,7 @@
We have open-sourced AutoFDO profile toolchain in:
https://github.com/google/autofdo
For GCC developers, the most important tool is create_gcov, which
converts sampling based profile to GCC-readable profile. Please refer
to the readme file
This patch backports r199154 from google-4_8 to google-4_9
Bootstrapped and passed regression test.
OK for google-4_9 branch?
Thanks,
Dehao
Index: gcc/final.c
===
--- gcc/final.c (revision 210329)
+++ gcc/final.c (working copy)
@@
Yes, this patch is a combination of all these patches. Some of them
are already in trunk.
Dehao
On Mon, May 12, 2014 at 1:28 PM, Cary Coutant ccout...@google.com wrote:
On Mon, May 12, 2014 at 1:11 PM, Dehao Chen de...@google.com wrote:
This patch backports r199154 from google-4_8 to google
The previous checkin will break build for most application:
http://gcc.gnu.org/viewcvs/gcc/branches/google/gcc-4_9/gcc/?view=log
This patch fixes the regression by updating highest_location.
Testing on-going,
OK for google-4_9 branch?
Thanks,
Dehao
Index: gcc/input.c
The problem is that linemap_location_from_macro_expansion_p will
always return true if locus has discriminator. And in linemap_lookup,
this will lead to call linemap_macro_map_lookup, in which there is an
assertion:
linemap_assert (line = LINEMAPS_MACRO_LOWEST_LOCATION (set));
However, line is
As discussed offline, this is actually due to missing parts of the
previous patch (some changes does not appear in the change log of
r199154). I've updated the patch to include those missing pieces.
Testing on going.
Dehao
On Tue, May 13, 2014 at 10:04 AM, Cary Coutant ccout...@google.com wrote:
Attached patch passes regression tests and benchmark test. OK for google-4_9?
Thanks,
Dehao
On Tue, May 13, 2014 at 10:43 AM, Dehao Chen de...@google.com wrote:
As discussed offline, this is actually due to missing parts of the
previous patch (some changes does not appear in the change log
if test pass?
Thanks,
Dehao
gcc/ChangeLog:
2014-05-16 Dehao Chen de...@google.com
* cfghooks.c (make_forwarder_block): Use direct computation to
get fall-through edge's count and frequency.
Index: gcc/cfghooks.c
This patch uses optimize_function_for_size_p to replace old
optimize_size check in regs.h and ira-int.h to make it consistent.
Bootstrapped and testing on-going.
OK for trunk if test passes?
Thanks,
Dehao
gcc/ChangeLog:
2014-05-16 Dehao Chen de...@google.com
* ira-int.h
This patch makes sure max count is used when merging two basic blocks.
Bootstrapped and testing on-going.
OK for trunk if test is ok?
Thanks,
Dehao
gcc/ChangeLog:
2014-05-16 Dehao Chen de...@google.com
* tree-cfg.c (gimple_merge_blocks): Updates bb count with max count.
Index: gcc
Is this patch ok for trunk? Bootstrapped and regression test on-going.
Thanks,
Dehao
2014-05-16 Dehao Chen de...@google.com
* tree-inline.c (initialize_cfun): Ensure count_scale is no larger
than REG_BR_PROB_BASE.
(copy_cfg_body): Likewise.
Index: gcc/tree-inline.c
On Fri, May 16, 2014 at 4:41 PM, Jan Hubicka hubi...@ucw.cz wrote:
Is this patch ok for trunk? Bootstrapped and regression test on-going.
Thanks,
Dehao
2014-05-16 Dehao Chen de...@google.com
* tree-inline.c (initialize_cfun): Ensure count_scale is no larger
Do you mean adjusting bb-count? Because in
expand_call_inline(tree-inline.c), it will use bb-count to pass into
copy_body to calculate count_scale.
Thanks,
Dehao
On Fri, May 16, 2014 at 5:22 PM, Jan Hubicka hubi...@ucw.cz wrote:
In AutoFDO, a basic block's count can be much larger than it's
I've updated the patch. Shall I move the check inside cgraph_clone_node?
Thanks,
Dehao
Index: gcc/ipa-inline-transform.c
===
--- gcc/ipa-inline-transform.c (revision 210535)
+++ gcc/ipa-inline-transform.c (working copy)
@@ -183,8
On Mon, May 19, 2014 at 1:40 PM, Jan Hubicka hubi...@ucw.cz wrote:
I've updated the patch. Shall I move the check inside cgraph_clone_node?
Thanks,
I think it is OK as it is. I belive individual users should know what do to
in such cases themselves.
You may want to also check what ipa-cp is
If a loop's header count is less than iteration count, the iteration
estimation is apparently incorrect for this loop. Thus disable
unrolling of such loops.
Testing on going. OK for trunk if test pass?
Thanks,
Dehao
gcc/ChangeLog:
2014-05-21 Dehao Chen de...@google.com
* cfgloop.h
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
===
--- gcc/ipa.c (revision 210864)
+++ gcc/ipa.c (working copy)
@@ -39,6 +39,7 @@
This patch updates the merged bb count only when they are in the same loop.
Bootstrapped and passed regression test.
Ok for trunk?
Thanks,
Dehao
gcc/ChangeLog:
2014-05-30 Dehao Chen de...@google.com
* tree-cfg.c (gimple_merge_blocks): Only reset count when BBs
As we are pushing AutoFDO patch upstream, is this patch OK for trunk?
Thanks,
Dehao
On Mon, Aug 19, 2013 at 1:32 PM, Dehao Chen de...@google.com wrote:
After rerunning test, this will fail one gcc regression test. So I
updated the patch to make sure all test will pass:
Index: gcc/dwarf2out.c
Chen de...@google.com wrote:
As we are pushing AutoFDO patch upstream, is this patch OK for trunk?
Thanks,
Dehao
On Mon, Aug 19, 2013 at 1:32 PM, Dehao Chen de...@google.com wrote:
After rerunning test, this will fail one gcc regression test. So I
updated the patch to make sure all test
Thanks for the suggestion. I actually want this function to be inlined
in ipa-inline phase, not einline phase.
Dehao
On Fri, May 30, 2014 at 4:50 PM, Steven Bosscher stevenb@gmail.com wrote:
On Fri, May 30, 2014 at 11:43 PM, Dehao Chen wrote:
Index: gcc/testsuite/gcc.dg/tree-prof
This patch rebuilds frequency after vrp.
Bootstrapped and testing on-going. OK for trunk if test pass?
Thanks,
Dehao
gcc/ChangeLog:
2014-06-02 Dehao Chen de...@google.com
PR tree-optimization/61384
* tree-vrp.c (execute_vrp): rebuild frequency after vrp.
gcc/testsuite
,
Dehao
gcc/ChangeLog:
2014-06-02 Dehao Chen de...@google.com
PR tree-optimization/61384
* tree-vrp.c (execute_vrp): rebuild frequency after vrp.
gcc/testsuite/ChangeLog:
2014-06-02 Dehao Chen de...@google.com
PR tree-optimization/61384
* gcc.dg/pr61384.c
Just tried with Teresa's patch, the ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61384 is not resolved.
Dehao
On Mon, Jun 2, 2014 at 9:45 AM, Jeff Law l...@redhat.com wrote:
On 06/02/14 10:17, Dehao Chen wrote:
We need to rebuild frequency after vrp, otherwise the following code
ping...
Dehao
On Fri, May 30, 2014 at 4:13 PM, Dehao Chen de...@google.com wrote:
This will increase c++ g1/g2 binary size a little. For all spec
cint2006 benchmarks, the binary size change is shown below.
400 0.00% 0.00% 0.00% 0.00%
401 0.00% 0.00% 0.00% 0.00%
403 0.00% 0.00% 0.00% 0.00
On Wed, Jun 11, 2014 at 10:38 AM, Cary Coutant ccout...@google.com wrote:
This will increase c++ g1/g2 binary size a little. For all spec
cint2006 benchmarks, the binary size change is shown below.
400 0.00% 0.00% 0.00% 0.00%
401 0.00% 0.00% 0.00% 0.00%
403 0.00% 0.00% 0.00% 0.00%
429 0.00%
. Ok for Google/4_8?
Teresa
2014-06-12 Teresa Johnson tejohn...@google.com
Dehao Chen de...@google.com
Google ref b/15521327.
* cgraphclones.c (cgraph_clone_edge): Use resolved node.
* l-ipo.c (resolve_cgraph_node): Resolve to non-removable node
ping...
Dehao
On Fri, Jan 24, 2014 at 1:54 PM, Dehao Chen de...@google.com wrote:
Thanks, test updated:
Index: gcc/testsuite/gcc.dg/predict-8.c
===
--- gcc/testsuite/gcc.dg/predict-8.c (revision 0)
+++ gcc/testsuite/gcc.dg
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
===
--- gcc/auto-profile.c
, 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 early_inliner, which would lead to ICE.
Testing on going, OK for google-4_8 if test passes?
Thanks,
Dehao
This patch removes the size limit for loop unroll/peel when the loop
is truly hot. This makes the implementation easily maintanable between
FDO and AutoFDO.
Bootstrapped and loadtest perf show neutral impact.
OK for google-4_8?
Thanks,
Dehao
Index: gcc/loop-unroll.c
Looks good to me.
Dehao
On Tue, Mar 11, 2014 at 3:22 PM, Hán Shěn (沈涵) shen...@google.com wrote:
Hi current google/main fails to build for arm because of duplicated
head file entries in gtyp-input.list.
Fixed by removing duplication in macro tm_file. This only affects arm
platform. Tested
During AutoFDO annotation, we want to record the annotation stats into
an elf section, so that we can calculate how much percentage of the
profile is annotated, which can be used as an indicator whether code
has changed significantly comparing with the profiled source.
Bootstrapped and
Thanks Cary for the comments.
Patch updated, an also added a tool in contrib/ to dump the profile
annotation coverage.
Dehao
On Wed, Mar 12, 2014 at 9:48 AM, Cary Coutant ccout...@google.com wrote:
+void autofdo_source_profile::write_annotated_count () const
+{
+ switch_to_section
Looks good to me.
Dehao
On Wed, Mar 12, 2014 at 3:35 PM, Hán Shěn (沈涵) shen...@google.com wrote:
ARM build (on chrome) is broken because of duplicate entries in arm.md
and unspecs.md. Fixed by removing duplication and merge those in
arm.md into unspecs.md.
(We had a similar fix for
This patch calls update_ssa before compute_inline_paramters.
Bootstrapped and perf test on-going.
OK for google-4_8?
Thanks,
Dehao
Index: gcc/auto-profile.c
===
--- gcc/auto-profile.c (revision 208726)
+++ gcc/auto-profile.c
) need_ssa_update_p (cfun))
flags |= TODO_update_ssa;
}
if (flags TODO_update_ssa_any)
{
unsigned update_flags = flags TODO_update_ssa_any;
update_ssa (update_flags);
cfun-last_verified = ~TODO_verify_ssa;
}
David
On Thu, Mar 20, 2014 at 10:39 AM, Dehao
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
Index: gcc/auto-profile.c
This patch guards autofdo annotation coverage recording with a flag.
Test on-going.
OK for google-4_8 if test passes?
Thanks,
Dehao
Index: gcc/auto-profile.c
===
--- gcc/auto-profile.c (revision 208753)
+++ gcc/auto-profile.c
ping ^2...
Dehao
On Mon, Feb 10, 2014 at 8:35 AM, Dehao Chen de...@google.com wrote:
ping...
Dehao
On Fri, Jan 24, 2014 at 1:54 PM, Dehao Chen de...@google.com wrote:
Thanks, test updated:
Index: gcc/testsuite/gcc.dg/predict-8.c
Hi,
This patch updates node's inline summary after edge_summary is
updated. Otherwise it could lead to incorrect inline summary.
Bootstrapped and gcc regression test on-going.
OK for trunk?
Thanks,
Dehao
gcc/ChangeLog:
2014-03-21 Dehao Chen de...@google.com
*ipa-inline.c (early_inliner
CPU. But you are
more than welcome to tune the propagation algorithm to get most out of
inaccurate instruction profile.
Cheers,
Dehao
On Tue, Oct 21, 2014 at 12:30 PM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
On 2014.10.20 at 14:21 -0700, Dehao Chen wrote:
+If @var{path} is specified
Looks like the perf data type is incompatible with quipper (perf data
parser). Can you send me the perf.data file so that I can take a look.
Thanks,
Dehao
On Tue, Oct 21, 2014 at 2:25 PM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
On 2014.10.21 at 13:53 -0700, Dehao Chen wrote
The patch tested OK. And I think it's a trivial patch, and already
committed it to trunk.
About the perf parser. I'm syncing the toolchain to head which should
already have newer kernel support.
Thanks,
Dehao
On Wed, Oct 22, 2014 at 10:07 AM, Xinliang David Li davi...@google.com wrote:
Can
crosstool tests.
Okay for google-4_7?
Thanks,
Dehao
gcc/ChangeLog.google-4_7
2012-12-10 Dehao Chen de...@google.com
* tree-streamer-out.c (write_ts_exp_tree_pointers): Disable
streaming out TREE_BLOCK.
Index: gcc/tree-streamer-out.c
On Mon, Dec 10, 2012 at 9:30 PM, Andrew Pinski pins...@gmail.com wrote:
On Mon, Dec 10, 2012 at 9:23 PM, Dehao Chen de...@google.com wrote:
Hi,
The location_block patch has failed lto-bootstrap. This is fixed by a
bunch of fixes in trunk. But we would rather not spend too much effort
profiles, and 1 means two profiles are identical. This
number is dumped if the instrumentation based profile is available and
-fdump-ipa-profile is specified.
Ok for mainline?
Thanks,
Dehao
2011-09-20 Dehao Chen de...@google.com
* profile.c (compute_branch_probabilities): Compute and dump
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01293.html
This patch records the compiler command-line flags to a .note section,
which could be used by FDO/LIPO.
Bootstrapped on x86_64, no regressions.
Is it ok for google/gcc-4_6 and google/main branches?
Thanks,
Dehao
gcc/ChangeLog.google-4_6:
2011-10-08 Dehao Chen de...@google.com
Add
build.
Thanks,
Dehao
On Sat, Oct 8, 2011 at 7:41 PM, Jakub Jelinek ja...@redhat.com wrote:
On Sat, Oct 08, 2011 at 06:43:47PM +0800, Dehao Chen wrote:
This patch records the compiler command-line flags to a .note section,
which could be used by FDO/LIPO.
Bootstrapped on x86_64, no regressions
On Sun, Oct 9, 2011 at 5:28 PM, Jakub Jelinek ja...@redhat.com wrote:
On Sun, Oct 09, 2011 at 09:18:25AM +0800, Dehao Chen wrote:
Unfortunately -frecord-gcc-switches cannot serve our purpose because
the recorded switches are mergable, i.e. the linker will merge all
options to a set of strings
How about .gnu.switches.text.quote_paths?
Thanks,
Dehao
On Tue, Oct 11, 2011 at 8:42 AM, Cary Coutant ccout...@google.com wrote:
Ok for google branches.
1) document the difference of this option with -grecord-gcc-switches
(this one only record codegen related options, and recorded in debug
Attached is the new patch. Bootstrapped on x86_64, no regressions.
gcc/ChangeLog.google-4_6:
2011-10-08 Dehao Chen de...@google.com
Add a flag (-frecord-gcc-switches-in-elf) to record compiler
command line options to .gnu.switches.text sections of
the object file
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01293.html
Thanks!
Dehao
OK for google-4_6
Dehao
On Wed, Apr 4, 2012 at 8:36 AM, Rong Xu x...@google.com wrote:
Hi,
Google branch only.
Backout this change due to performance regression.
Tested with bootstrap.
Thanks,
-Rong
2012-04-03 Rong Xu x...@google.com
Google ref b/6284235.
/ChangeLog.google-4_6
2012-05-03 Dehao Chen de...@google.com
* predict.c (predict_iv_comparison): Add the comparison of induction
variable against its initial value. (Reenable r185948)
gcc/testsuite/ChangeLog.google-4_6
2012-05-03 Dehao Chen de...@google.com
* gcc.dg/predict-1.c
,
Dehao
gcc/ChangeLog
2012-05-04 Dehao Chen de...@google.com
* predict.c (find_qualified_ssa_name): New
(find_ssa_name_in_expr): New
(find_ssa_name_in_assign_stmt): New
(is_comparison_with_loop_invariant_p): New
(is_bound_expr_similar): New
Hi, Honza,
Thanks for the prompt response. Attached is the updated patch.
Passed bootstrap and all regression tests.
Thanks,
Dehao
Index: gcc/testsuite/gcc.dg/predict-3.c
===
--- gcc/testsuite/gcc.dg/predict-3.c(revision 0)
?
Thanks,
Dehao
gcc/ChangeLog
2012-05-08 Dehao Chen de...@google.com
* common.opt (feliminate-malloc): New.
* doc/invoke.texi: Document it.
* tree-ssa-dce.c (mark_stmt_if_obviously_necessary): Honor it.
gcc/testsuite/ChangeLog
2012-05-08 Dehao Chen de...@google.com
Sorry for the error. Here is a new patch to fix them:
gcc/testsuite/ChangeLog:
2012-05-08 Dehao Chen de...@google.com
* gcc.dg/predict-1.c: Remove the replicated text in this text.
* gcc.dg/predict-2.c: Likewise.
* gcc.dg/predict-3.c: Likewise.
* gcc.dg/predict
, and
a program may use this free(malloc()) pair to simulate the real runs
to get some data, such as peak memory requirement.
Dehao
Richard.
David
On Tue, May 8, 2012 at 7:43 AM, Dehao Chen de...@google.com wrote:
Hello,
This patch adds a flag to guard the optimization that optimize
On Wed, May 9, 2012 at 5:22 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, May 9, 2012 at 10:38 AM, Dehao Chen de...@google.com wrote:
On Wed, May 9, 2012 at 4:12 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, May 8, 2012 at 6:18 PM, Xinliang David Li davi
this).
Bootstrapped and passed gcc regression test.
Is it ok for trunk?
Thanks,
Dehao
gcc/ChangeLog
2012-07-30 Dehao Chen de...@google.com
* predict.c (predict_loops): Fix the prediction of LOOP_BRANCH.
gcc/testsuite/ChangeLog
2012-07-31 Dehao Chen de...@google.com
;
29 }
30 }
31 return;
32 }
The deallocator for 23 t test is called in two places: Line 28 and
line 30. However, gcc attributes both callsites to line 30.
Bootstrapped and passed gcc regression tests.
Is it ok for trunk?
Thanks,
Dehao
gcc/ChangeLog
2012-07-31 Dehao Chen de
not
bother with PRED_LOOP_EXIT. */
!predicted_by_p (bb, PRED_LOOP_ITERATIONS_GUESSED)
On Tue, Jul 31, 2012 at 5:18 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, Jul 31, 2012 at 5:17 AM, Dehao Chen de...@google.com wrote:
Hi,
This patch fixed the problem when
On Tue, Jul 31, 2012 at 6:56 PM, Jan Hubicka hubi...@ucw.cz wrote:
Yeah, this may also work. The reason it is not done is that
1) it seemed expensive to force CFG changes just to compute profile
decade ago
2) cfgcleanup afterwards will anyway remove the headers again.
So I
Thanks, Honza,
Then shall I check in the following patch to trunk (after testing)?
Dehao
Index: gcc/testsuite/gcc.dg/predict-7.c
===
--- gcc/testsuite/gcc.dg/predict-7.c(revision 0)
+++ gcc/testsuite/gcc.dg/predict-7.c
Ping...
Richard, could you shed some lights on this?
Thanks,
Dehao
On Mon, Jul 30, 2012 at 8:29 PM, Dehao Chen de...@google.com wrote:
Hi,
This patch fixes the source location for automatically generated calls
to deallocator. For example:
19 void foo(int i)
20 {
21 for (int j = 0
On Wed, Aug 8, 2012 at 8:56 AM, Richard Henderson r...@redhat.com wrote:
On 08/07/2012 06:25 AM, Richard Guenther wrote:
(is re-setting _every_ stmt location really ok in all cases?)
I'm certain that it's not, though you can't tell that from C++.
Examine instead a Java test case using
On Thu, Aug 9, 2012 at 3:06 PM, Jason Merrill ja...@redhat.com wrote:
On 08/08/2012 12:32 PM, Richard Henderson wrote:
On 08/08/2012 09:27 AM, Dehao Chen wrote:
Then we should probably assign UNKNOWN_LOCATION for these destructor
calls, what do you guys think?
I think it's certainly
On Fri, Aug 10, 2012 at 10:52 AM, Richard Henderson r...@redhat.com wrote:
On 2012-08-10 10:21, Dehao Chen wrote:
Yes, cxx_maybe_build_cleanup sets it to UNKNOWN_LOCATION, but during
gimplifying, it's reset to input_location:
gimplify.c (gimplify_call_expr)
2486 /* For reliable
On Fri, Aug 10, 2012 at 12:04 PM, Richard Henderson r...@redhat.com wrote:
On 2012-08-10 11:01, Dehao Chen wrote:
On Fri, Aug 10, 2012 at 10:52 AM, Richard Henderson r...@redhat.com wrote:
On 2012-08-10 10:21, Dehao Chen wrote:
Yes, cxx_maybe_build_cleanup sets it to UNKNOWN_LOCATION
On Fri, Aug 10, 2012 at 3:11 PM, Richard Henderson r...@redhat.com wrote:
On 2012-08-10 14:55, Dehao Chen wrote:
I see your point. But the problem is that the above code is in
gimplify_call_expr, in which we have no idea if it is in a
TRY_FINALLY/TRY_CATCH block.
That's why I suggested
1 - 100 of 395 matches
Mail list logo
