Sounds reasonable. The patch is updated, bootstrapped and passed all
regression test.
Dehao
On Tue, May 21, 2013 at 5:34 AM, Richard Biener
wrote:
> On Fri, May 17, 2013 at 5:48 PM, Dehao Chen wrote:
>> On Fri, May 17, 2013 at 1:22 AM, Richard Biener
>> wrote:
>>> On W
Fixed the problem, and retested. New patch attached.
Dehao
On Mon, May 20, 2013 at 3:53 PM, Cary Coutant wrote:
>>> I've updated the patch. Bootstrapped and passed all regression test.
>>>
>>> OK for google-4_8?
>
> Index: gcc/Makefile.in
> ===
forgot to attache the patch...
On Mon, May 20, 2013 at 3:39 PM, Dehao Chen wrote:
> I've updated the patch. Bootstrapped and passed all regression test.
>
> OK for google-4_8?
>
> Thanks,
> Dehao
>
> On Mon, May 20, 2013 at 10:48 AM, Cary Coutant wrote:
>>&g
I've updated the patch. Bootstrapped and passed all regression test.
OK for google-4_8?
Thanks,
Dehao
On Mon, May 20, 2013 at 10:48 AM, Cary Coutant wrote:
>> Cool. So shall we get this patch in gcc-4_8 first, and after you
>> change to encode discriminator in adhoc_locus map in trunk, we then
On Mon, May 20, 2013 at 9:37 AM, Cary Coutant wrote:
>>> I think the problem is with same_line_p. It's using expand_location to
>>> test whether two locations refer to the same line, but expand_location
>>> always unwinds the macro stack so that it's looking at the line number
>>> of the macro exp
On Fri, May 17, 2013 at 4:35 PM, Cary Coutant wrote:
>> The warning was attributed to the wrong lineno. Looks like
>> discriminator does not work well when it coexists with macros.
>
> I think the problem is with same_line_p. It's using expand_location to
> test whether two locations refer to the
On Fri, May 17, 2013 at 1:22 AM, Richard Biener
wrote:
> On Wed, May 15, 2013 at 6:50 PM, Cary Coutant wrote:
>>> gcc/ChangeLog:
>>>
>>> * tree-cfg.c (locus_descrim_hasher::hash): Only hash lineno.
>>> (locus_descrim_hasher::equal): Likewise.
>>> (next_discriminator_for_locus): Likewise.
>>> (ass
On Wed, May 15, 2013 at 3:44 PM, Cary Coutant wrote:
>> The warning was attributed to the wrong lineno. Looks like
>> discriminator does not work well when it coexists with macros.
>
> I think warn_uninit in tree-ssa.c needs one of these:
>
> location = map_discriminator_location (location);
>
>
On Wed, May 15, 2013 at 9:50 AM, Cary Coutant wrote:
>> gcc/ChangeLog:
>>
>> * tree-cfg.c (locus_descrim_hasher::hash): Only hash lineno.
>> (locus_descrim_hasher::equal): Likewise.
>> (next_discriminator_for_locus): Likewise.
>> (assign_discriminator): Add return value.
>> (make_edges): Assign mo
The warning was attributed to the wrong lineno. Looks like
discriminator does not work well when it coexists with macros.
Dehao
On Wed, May 15, 2013 at 9:58 AM, Cary Coutant wrote:
>> Bootstrapped. It will fail gcc.dg/uninit-6-O0.c, which also fails in
>> google-4_7 branch.
>
> It'd be nice to f
This patch fixes a common case where one line is distributed to 3 BBs,
but only 1 discriminator is assigned.
Bootstrapped and passed gcc regression test.
OK for trunk?
Thanks,
Dehao
gcc/ChangeLog:
* tree-cfg.c (locus_descrim_hasher::hash): Only hash lineno.
(locus_descrim_hasher::equal): Likew
This patch ports r173196 from google-main and r190269 from google-4_7
to add discriminator support in google-4_8 branch.
Bootstrapped. It will fail gcc.dg/uninit-6-O0.c, which also fails in
google-4_7 branch.
OK to backport to google-4_8 branch?
Thanks,
Dehao
Index: gcc/gimple-pretty-print.c
===
wrote:
> Looks good.
>
> David
>
> On Sat, May 11, 2013 at 3:53 PM, Dehao Chen wrote:
>> In AutoFDO, we early-inline callsites that was inlined in profiling
>> runs regardless of the size limit. With this change, the existing
>> ipa-inline tunings for AutoFDO is unn
In AutoFDO, we early-inline callsites that was inlined in profiling
runs regardless of the size limit. With this change, the existing
ipa-inline tunings for AutoFDO is unnecessary: it's fine to just use
the traditional FDO based heuristic. This patch cleans up the original
tunings and make it easie
On Fri, May 10, 2013 at 11:32 AM, Teresa Johnson wrote:
> On Fri, May 10, 2013 at 11:00 AM, Dehao Chen wrote:
>> On Fri, May 10, 2013 at 10:47 AM, Teresa Johnson
>> wrote:
>>> Is it only auto fdo that doesn't store the module info if the module
>>> is not
ay 10, 2013 at 11:00 AM, Dehao Chen wrote:
>> On Fri, May 10, 2013 at 10:47 AM, Teresa Johnson
>> wrote:
>>> Is it only auto fdo that doesn't store the module info if the module
>>> is not exported or has aux modules? Note that this will prevent usage
>>> o
se it does not use the id at all in the profile (instead,
it stores the function name directly).
Thanks,
Dehao
>
> Teresa
>
> On Fri, May 10, 2013 at 10:37 AM, Dehao Chen wrote:
>> Now we don't store the module info if the module is not exported or
>> has any aux module
Now we don't store the module info if the module is not exported or
has any aux module (to compress the profile data size). Thus it's
normal that a primary module entry cannot be found. This patch
suppresses the messages printed when the primary module is not found.
Bootstrapped and passed regress
This patch updated the unittest and doc for the new
-frecord-compilation-info-in-elf flag.
Bootstrapped and passed regression test.
OK for google-4_7 branch?
Thanks,
Dehao
Index: gcc/testsuite/gcc.dg/record-gcc-switches-in-elf-1.c
elete", "-fno-sized-delete", false },
{ "-frtti", "-fno-rtti", true },
{ "-fstrict-aliasing", "-fno-strict-aliasing", true },
+{ "-fsigned-char", "-funsigned-char", true},
{ NULL, NULL, false }
};
Ok for goo
I see a case when the DECL_ASSEMBLER_NAME has " *INTERNAL* " as the suffix.
Dehao
On Wed, May 1, 2013 at 9:49 AM, Teresa Johnson wrote:
> On Wed, May 1, 2013 at 8:01 AM, Dehao Chen wrote:
>> The patch is updated to fix some bugs in the impl.
>>
>> Thanks,
&g
I've seen a case when func_id in aux module is not the same (off by
1). This is when -fexception is specified. I had not looked into why
though. I'll find out why it is off-by-1
Dehao
On Wed, May 1, 2013 at 9:57 AM, Xinliang David Li wrote:
> On Tue, Apr 30, 2013 at 4:10 PM, Deha
;
seq = get_name_seq_num (assembler_name);
if (seq)
sprintf (assembler_name, "%s.%d", assembler_name, seq);
On Tue, Apr 30, 2013 at 4:10 PM, Dehao Chen wrote:
> This patch changes to use context function name to replace function
> id, which is not available in Au
This patch changes to use context function name to replace function
id, which is not available in AutoFDO builds.
Bootstrapped and passed regression tests.
OK for google branches?
Thanks,
Dehao
Index: gcc/l-ipo.c
===
--- gcc/l-ipo.
This patch improves the LIPO support in AutoFDO to make it more robust.
Bootstrapped and passed regression test and benchmark tests.
Ok for google 4_7 branch?
Thanks,
Dehao
http://codereview.appspot.com/8624045
Index: gcc/opts.h
=
This patch forbids modules to be imported as aux module if its --std
is different with the primary module.
Bootstrapped and passed regression test.
OK for google branches?
Thanks,
Dehao
Index: gcc/coverage.c
===
--- gcc/coverage.c
Bootstrapped and passed regression tests.
Okay for google-4_7 and google-4_7 branches?
Thanks,
Dehao
2012-03-09 Rong Xu
* opts-global.c (lipo_save_cl_args): save -std option.
Google ref b/6117980.
Index: gcc/opts-global.c
The ported patch:
r188371 | dehao | 2012-06-09 18:44:58 -0700 (Sat, 09 Jun 2012) | 13 lines
2012-06-10 Dehao Chen
Backport r188303 from google-4_7
* gcc/cgraph.c (cgraph_node): Add attribute to function decl.
* gcc/opts-global.c (add_attribute_pattern): New function
Looks good.
Dehao
On Wed, Apr 24, 2013 at 5:49 PM, Han Shen(沈涵) wrote:
> Hi, this patch back port trunk@198101 to fix PR rtl-optimization/56847.
>
> Passed bootstrap and regression test.
>
> Ok for branch google/gcc-4_8?
>
> 2013-04-19 Vladimir Makarov
>
> PR rtl-optimization/56847
>
ation (loc).line;
pos_stack[idx - 1].func =
On Sun, Apr 21, 2013 at 5:00 PM, Teresa Johnson wrote:
> On Sun, Apr 21, 2013 at 4:51 PM, Dehao Chen wrote:
>> This patch fixed a bug in getting inline stacks: if there is no
>> location info attached to a block, we should *not* try to g
This patch fixed a bug in getting inline stacks: if there is no
location info attached to a block, we should *not* try to get its
function name because it could result in infinite loop.
Bootstrapped and passed all regression tests.
Ok for gcc-4_7 branch?
Thanks,
Dehao
Index: gcc/auto-profile.c
This patch fixes LIPO support in AutoFDO.
Bootstrapped and passed regression tests.
OK for google-4_7 branch?
Thanks,
Dehao
Index: gcc/coverage.c
===
--- gcc/coverage.c (revision 198056)
+++ gcc/coverage.c (working copy)
@@ -2857,7
This patch implements indirect call promotion for AutoFDO.
Bootstrapped and passed gcc regression tests.
Is it okay for gcc-4_7 branch?
Thanks,
Dehao
http://codereview.appspot.com/8814043
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index d17b250..c217846 100644
--- a/gcc/Makefile.in
+++ b/g
Hi,
This patch fix the bug of sum_all, which is used in loop unroll. The
fix will suppress unrolling loops when the program is hot instruction
footprint is large.
Bootstrapped and passed regression tests.
Is it okay for googe-4_7 branch?
Thanks,
Dehao
--- a/gcc/auto-profile.c
+++ b/gcc/auto-pr
Hi,
This patch
1. Uses relative line offset (lineno - start_lineno_of_function) to
represent AutoFDO profile. This ensures profile still work for
modified source code.
2. When matching the profile, add function name (bfd_name) to match
the inline stack.
Bootstrapped and passed regression tests.
In the current implementation, update_all_callee_keys only invokes
update_caller_keys for one edge. For the AutoFDO case, it could cause
important edges not being updated because top-down inline pattern is
very popular in AutoFDO. This patch ensures all edges are updated in
update_caller_keys.
Boo
Hi,
This patch updates the function frequency after calculating branch
probability. This is important because cold function could be promoted
to hot after ipa-inline.
Bootstrapped and passed gcc regression tests.
Okay for google-4_7?
Thanks,
Dehao
--- a/gcc/predict.c
+++ b/gcc/predict.c
@@ -28
ase) ? DECL_SOURCE_LOCATION (base)
: EXPR_LOCATION (base);
- loc = EXPR_LOCATION (base);
if (TREE_CODE (base) != ADDR_EXPR
&& POINTER_TYPE_P (TREE_TYPE (base)))
On Fri, Mar 22, 2013 at 3:46 PM, Dehao Chen wrote:
> Hi,
>
> This patch fixes the error in r193861, which bac
Hi,
This patch fixes the error in r193861, which backported r193857 from trunk.
Bootstrapped and passed all gcc regression tests.
Is it okay for google-4_7?
Thanks,
Dehao
Looks good.
Dehao
On Fri, Mar 8, 2013 at 11:07 AM, Han Shen(沈涵) wrote:
> Hi Ahmad and Dehao, gcc-4_7-mobile branch needs 196555 patch to fix
> broken dependency when bootstrapping host compiler for chromeos.
>
> Could you take a look, thanks!
>
> -Han
>
> Patch here >>
> diff --git a/gcc/Makefil
This patch fixes the incorrect dependency in Makefile.in.
Bootstrapped and passed regression test.
Okay for google-4_7 branch?
Thanks,
DehaoIndex:
gcc/Makefile.in
===
--- gcc/Makefile.in (revision 196532)
+++ gcc/Makefile.in (worki
On Mon, Dec 10, 2012 at 9:30 PM, Andrew Pinski wrote:
>
> On Mon, Dec 10, 2012 at 9:23 PM, Dehao Chen 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
crosstool tests.
Okay for google-4_7?
Thanks,
Dehao
gcc/ChangeLog.google-4_7
2012-12-10 Dehao Chen
* tree-streamer-out.c (write_ts_exp_tree_pointers): Disable
streaming out TREE_BLOCK.
Index: gcc/tree-streamer-out.c
On Tue, Nov 27, 2012 at 1:46 AM, Richard Biener
wrote:
> On Mon, Nov 26, 2012 at 11:54 PM, Dehao Chen wrote:
>> The new patch is attached. Bootstrapped and passed gcc regression test.
>>
>> Ok for trunk?
>
> Hmm ... this merely avoids some UNKNOWN_LOCATIONs which s
The new patch is attached. Bootstrapped and passed gcc regression test.
Ok for trunk?
Thanks,
Dehao
gcc/ChangeLog:
2010-11-05 Dehao Chen
* ipa-prop.c (ipa_modify_call_arguments): Set loc correctly.
* emit-rtl.c (last_location): Remove unused variable.
Index: gcc/emit-rtl.c
Hi,
This patch fixes a bug of comparing goto_locus to UNKNOWN_LOCATION
when combining basic blocks.
Bootstrapped and and passed gcc regression tests.
Is it okay for trunk?
Thanks,
Dehao
gcc/ChangeLog:
2012-11-26 Dehao Chen
* cfgrtl.c (rtl_merge_blocks): Check with UNKNOWN_LOCATION
On Mon, Nov 26, 2012 at 8:10 AM, Richard Biener
wrote:
> On Mon, Nov 26, 2012 at 4:54 PM, Dehao Chen wrote:
>> On Mon, Nov 26, 2012 at 7:28 AM, Richard Biener
>> wrote:
>>> On Thu, Nov 8, 2012 at 6:39 PM, Dehao Chen wrote:
>>>> ping...
>>>
>&g
On Mon, Nov 26, 2012 at 7:28 AM, Richard Biener
wrote:
> On Thu, Nov 8, 2012 at 6:39 PM, Dehao Chen wrote:
>> ping...
>
> The emit-rtl.c hunk is ok. I'm questioning the ipa-prop.c hunk though - what
> looks at input_location (nothing outside of the
On Sun, Nov 25, 2012 at 11:37 AM, Xinliang David Li wrote:
> On Sun, Nov 25, 2012 at 4:40 AM, Richard Biener
> wrote:
>> On Thu, Nov 15, 2012 at 5:46 PM, Eric Botcazou wrote:
But UNKNOWN_LOCATION is effectively wrong as well. If other
optimizations move the statements above the insert
Yeah, at least for the unittest I provided, the coverage info will be
wrong without the patch.
Thanks,
Dehao
On Thu, Nov 15, 2012 at 10:30 AM, Xinliang David Li wrote:
> I probably made too general statement in this topic. However for the
> PRE case, I believe the choice of not using UNKNOWN loc
On Thu, Nov 15, 2012 at 8:46 AM, Eric Botcazou wrote:
>
> > But UNKNOWN_LOCATION is effectively wrong as well. If other
> > optimizations move the statements above the inserted instruction, then
> > the new instruction ends up inheriting whatever location happens to be
> > in the previous stateme
ping...
On Wed, Oct 31, 2012 at 5:26 PM, Dehao Chen wrote:
> Hi,
>
> When -fcompare_debug is used, what we really want to do is to compare
> instructions between the -g version and -gtoggle version. However,
> current dump file still contains the source line in its rtl dump. This
ping...
On Mon, Nov 5, 2012 at 5:20 PM, Dehao Chen wrote:
>
> Hi,
>
> This is a patch to do some obvious cleanup and setting correct
> input_location in ipa_prop (because it invokes gimplification
> routines).
>
> Bootstrapped and passed gcc regression tests.
Hi,
This is a patch to do some obvious cleanup and setting correct
input_location in ipa_prop (because it invokes gimplification
routines).
Bootstrapped and passed gcc regression tests.
Is it okay for trunk?
Thanks,
Dehao
gcc/ChangeLog:
2010-11-05 Dehao Chen
* ipa-prop.c
> No, there is nothing natural (and this can even be wrong). The statements
> must have the source location corresponding to the source construct they are
> generated for, which may be totally different from that of the insertion
> point. Yes, that can generate jumpiness in GDB, but this is far b
> OK, thanks. What happens if you go one step farther and always continue?
Because we do want location and its block to be tightly coupled. I may
want to add an assertion that if location is known, the block should
*not* be NULL.
Dehao
>
> --
> Eric Botcazou
2. __attribute__((noinline)) int abc (int *a)
3. {
4. int ret = 0;
5.
6. if (x > 0)
7.ret += *a;
8. else
9.a++;
10.
11. ret += *a;
12. return ret;
13 }
In terms of jumpiness, without the patch, the jump sequence is:
2 -> 13 -> 4 -> 11 -> 13
With the patch, the jump sequence is:
2-> 9
sts.
Is it okay for trunk?
Thanks,
Dehao
gcc/ChangeLog:
2012-11-02 Dehao Chen
* final.c (reemit_insn_block_notes): Do not change scope if insn
location is UNKNOWN_LOCATION.
block.patch
Description: Binary data
On Thu, Nov 1, 2012 at 4:07 PM, Xinliang David Li wrote:
> On Thu, Nov 1, 2012 at 3:57 PM, Ian Lance Taylor wrote:
>> On Thu, Nov 1, 2012 at 10:00 AM, Dehao Chen wrote:
>>>
>>> I see your point. How about we guard these changes with a flag, say
>>> -gless-jum
Hi,
In r193053, input_location was mistakenly used. This patch changed to
use curr_insn_location instead. This looks like an obvious patch, can
I check it in to trunk?
Bootstrapped and passed gcc/gdb regression test.
Thanks,
Dehao
gcc/ChangeLog:
2012-11-01 Dehao Chen
* expr.c
Hi, Eric,
I see your point. How about we guard these changes with a flag, say
-gless-jumpy, so that people can always choose between better coverage
and less jumpy gdb behavior (it's also important for some other
clients like AutoFDO). I will have a series of patches to follow soon
that can be gua
for instructions moved to other BB, is it acceptable?
Thanks,
Dehao
>
>> gcc/ChangeLog:
>> 2012-10-31 Dehao Chen
>>
>> * emit-rtl.c (reorder_insns): Reset the source location for
>> instructions moved out of its original residing basic block.
>
> No, that isn't acceptable.
>
> --
> Eric Botcazou
.
Bootstrapped and passed gcc regression test.
Is it okay for trunk?
Thanks,
Dehao
gcc/ChangeLog:
2012-10-31 Dehao Chen
* emit-rtl.c (reorder_insns): Reset the source location for
instructions moved out of its original residing basic block.
gcc/testsuite/ChangeLog:
2012-10-31
passed gcc regression test on x86_64.
Is it okay for trunk?
Thanks,
Dehao
2012-10-31 Dehao Chen
* final.c (rest_of_clean_state): Dump the final rtl without location.
compare_debug.patch
Description: Binary data
> Yeah. But please also check gdb testsuite for this kind of patches.
This patch also passed gdb testsuite.
Thanks,
Dehao
>
> Jakub
onents / operation.
>
> Thus I think inserted expressions should not have any debug information
> at all because they do not correspond to a source line.
>
> Richard.
>
>> David
>>
>> On Tue, Oct 30, 2012 at 4:38 PM, Steven Bosscher
>> wrote:
>>>
Sorry, new patch attached...
On Tue, Oct 30, 2012 at 4:38 PM, Steven Bosscher wrote:
> On Wed, Oct 31, 2012 at 12:00 AM, Dehao Chen wrote:
>> This patch aims to improve debugging of optimized code. It ensures
>> that PRE inserted statements have the same source location as the
for trunk?
Thanks,
Dehao
gcc/ChangeLog:
2012-10-30 Dehao Chen
* tree-ssa-pre.c (insert_into_pred_update_location): New Function.
(insert_into_preds_of_block): Update source location for inserted stmts.
gcc/testsuite/ChangeLog:
2012-10-30 Dehao Chen
* gcc.dg/debug
> gcc/ChangeLog:
> 2012-10-25 Dehao Chen
>
> * tree-eh.c (do_return_redirection): Set location for jump statement.
> (do_goto_redirection): Likewise.
> (frob_into_branch_around): Likewise.
> (lower_try_finally_
> The debugger isn't the only consumer of debug info, and other tools might need
> a finer granularity than a GIMPLE location, so clearing EXPR_LOCATION to work
> around a debug info size issue seems very short-sighted (to say the least).
Hi, Eric,
There might be some misunderstanding here. Clear
BTW, one thing I found confusing is that in expr.c, some code is for
frontend, while some are for rtl. Shall we separate them into two
files? And we don't expect to see EXPR_LOCATION in the rtl side.
Thanks,
Dehao
ed.
I agree, but this looks like too bold a move at this point. Shall we
do that in 4.8?
BTW, I updated the patch to ensure pr43479.c works fine. The testing
is still on-going.
Dehao
gcc/ChangeLog:
2012-10-25 Dehao Chen
* tree-eh.c (do_return_redirection):
> And tree expressions don't have TREE_BLOCK before gimple-low either.
> So IMNSHO it is gimple-low.c that should set TREE_BLOCK of all the gimple
> stmts as well as all expression in the operands. It is not overwriting
> anything, no frontend sets TREE_BLOCK for any expression, the way frontends
Yeah, I looked into the testcase. Indeed, the expr location should be
used instead of curr_insn_location(). Otherwise the source line for
all definitions will be attributed to the use point. But if we use
EXPR_LOCATION, then we need to make sure the block is also correct.
Any suggestions how we sh
): Likewise.
* expr.c (store_expr): Use current insn location instead of expr
location.
(expand_expr_real): Likewise.
(expand_expr_real_1): Likewise.
gcc/testsuite/ChangeLog:
2012-10-25 Dehao Chen
* g++.dg/debug/dwarf2/block.C: New testcase.
Index: gcc
Ok. I'll test Micheal's patch, and send out the new patch soon.
Thanks,
Dehao
widely after gimplification. Do you mean that in the long run, we'd
want to remove all these?
Thanks,
Dehao
On Mon, Oct 29, 2012 at 9:49 AM, Dehao Chen wrote:
> On Mon, Oct 29, 2012 at 9:10 AM, Richard Biener
> wrote:
>> On Mon, Oct 29, 2012 at 4:25 PM, Dehao Chen wrote:
&
On Mon, Oct 29, 2012 at 9:10 AM, Richard Biener
wrote:
> On Mon, Oct 29, 2012 at 4:25 PM, Dehao Chen wrote:
>> On Mon, Oct 29, 2012 at 7:17 AM, Michael Matz wrote:
>>> Hi,
>>>
>>> On Mon, 29 Oct 2012, Richard Biener wrote:
>>>
>>>> > W
On Mon, Oct 29, 2012 at 7:17 AM, Michael Matz wrote:
> Hi,
>
> On Mon, 29 Oct 2012, Richard Biener wrote:
>
>> > Well, you merely moved the bogus code to gimple-low.c. It is bogus
>> > because you unconditionally overwrite TREE_BLOCK of all operands (and all
Emm, then in gimple-low.c, we should
On Sat, Oct 27, 2012 at 11:07 AM, Richard Biener
wrote:
> On Sat, Oct 27, 2012 at 12:53 AM, Dehao Chen wrote:
>> Hi,
>>
>> I've updated the patch:
>>
>> 1. abandon the changes in cfgexpand.c
>> 2. set the block for trees when lowering gimple stmt.
also there even without the patch. This patch
just reveal the problem by moving a decl into cache so that it will be
checked. As I'm not familiar with LTO, not quite sure what the root
problem is. Can anyone help take a look?
Thanks,
Dehao
gcc/ChangeLog:
2012-10-25 Dehao Chen
*
r is fixed by this patch I sent. Thus after this patch,
the block_location improvement will not cause regression to gdb tests.
Thanks,
Dehao
On Thu, Oct 25, 2012 at 11:53 AM, Dehao Chen wrote:
> On Thu, Oct 25, 2012 at 11:11 AM, Tom Tromey wrote:
>>>>>>> "Dehao" ==
On Thu, Oct 25, 2012 at 11:11 AM, Tom Tromey wrote:
>>>>>> "Dehao" == Dehao Chen writes:
>
> Dehao> This patch fixes debug info for expr and jump stmt.
> Dehao> Bootstrapped and passed gcc regression tests.
> Dehao> Is it okay for trunk?
>
On Thu, Oct 25, 2012 at 11:06 AM, Eric Botcazou wrote:
>> This patch fixes debug info for expr and jump stmt.
>
> It would be nice to have testcases...
Sure, I'll try to forge some testcases for this.
>
>> * cfgexpand.c (set_expr_location_r): New callback function.
>> (gimple_assign_rhs_to_tree)
Hi,
This patch fixes debug info for expr and jump stmt.
Bootstrapped and passed gcc regression tests.
Is it okay for trunk?
Thanks,
Dehao
gcc/ChangeLog:
2012-10-25 Dehao Chen
* tree-eh.c (do_return_redirection): Set location for jump statement.
(do_goto_redirection): Likewise
This patch was committed and ported to google-4_7 branch.
Thanks,
Dehao
gcc/ChangeLog:
2012-10-07 Dehao Chen
* tree-eh.c (lower_try_finally_onedest): Set correct location for
deallocator.
* gimplify.c (gimplify_expr): Set correct location for TRY stmt.
gcc/cp/ChangeLog:
2012-10-07 Dehao
The patch bootstrapped and passed gcc regression tests.
Thanks,
Dehao
On Tue, Oct 9, 2012 at 1:16 PM, Dehao Chen wrote:
> Yes, you are right. I've changed to use EXPR_LOCATION (stmt) for the location.
>
> New patch attached, testing is on-going.
>
> Thanks,
> Dehao
>
&
Yes, you are right. I've changed to use EXPR_LOCATION (stmt) for the location.
New patch attached, testing is on-going.
Thanks,
Dehao
On Tue, Oct 9, 2012 at 12:35 PM, Jason Merrill wrote:
> On 10/07/2012 08:38 PM, Dehao Chen wrote:
>>
>> +*stmt_p = build2_loc (input_loc
I have backported the following patches from trunk to google-4_7:
191931, 192049, 192120, 192165
gcc:
2012-10-08 Dehao Chen
Backport 191931, 192049, 192120, 192165 from trunk.
* tree-vect-loop-manip.c (slpeel_make_loop_iterate_ntimes): Use
LOCATION_LOCUS to compare
I have backported r192215 from trunk to google-4_7:
2012-10-08 Dehao Chen
* predict.c (predict_extra_loop_exits): Use
predict_paths_leading_to_edge to replace predict_edge_def.
Bootstrapped and passed crosstool test.
Dehao
Attached is the updated patch. Yes, if we add a VRP pass before
profile pass, this patch would be unnecessary. Should we add a VRP
pass?
Thanks,
Dehao
On Sat, Oct 6, 2012 at 9:38 AM, Jan Hubicka wrote:
>> ping^2
>>
>> Honza, do you think this patch can make into 4.8 stage 1?
>
> + if (check
Hi,
R191338 did not completely fix the location for deallocator. This
patch covers more cases for deallocator.
Bootstrapped and passed gcc regression test on x86.
Okay for trunk?
Thanks,
Dehao
gcc/ChangeLog:
2012-10-07 Dehao Chen
* tree-eh.c (lower_try_finally_onedest): Set correct
On Sat, Oct 6, 2012 at 6:13 PM, Andi Kleen wrote:
> Jan Hubicka writes:
>>
>> I think it is useful feature, yes (and was in my TODO list for quite some
>> time). Unlike edge profiles, these profiles should be also more independent
>> of
>> source code/configuration changes.
>
> It would be good
gt; source code/configuration changes.
Thanks for your feedback and interest. Yes, in AutoFDO the coupling
between the profiling build and fdo build are much loosen.
>
> Just few quick questions from first glance over the patch...
>>
>> Dehao
>>
>> The patch c
ping^2
Honza, do you think this patch can make into 4.8 stage 1?
Thanks,
Dehao
On Wed, Sep 26, 2012 at 2:34 PM, Dehao Chen wrote:
> http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01975.html
>
> Thanks,
> Dehao
Hi,
This patch fixes PR54826. When lowering the gimple, the block for call
arg also need to be reset.
Bootstrapped and passed gcc regression test on x86.
Okay for trunk?
Thanks,
Dehao
2012-10-05 Dehao Chen
* gimple-low.c (lower_stmt): Set the block for call args.
Index: gcc/gimple
Thanks for the comments. The patch was updated as attached.
Dehao
On Wed, Oct 3, 2012 at 11:46 AM, Jakub Jelinek wrote:
> On Wed, Oct 03, 2012 at 11:26:09AM -0700, Dehao Chen wrote:
>> @@ -6340,6 +6341,20 @@ move_block_to_fn (struct function *dest_cfun, basi
>>
Hi,
Attached patch fixes PR54782. phi_arg_location is not correctly
updated in move_block_to_fn. This patch fixes the problem.
Bootstrapped and passed gcc regression tests on x86.
Okay for trunk?
Thanks,
Dehao
gcc/ChangeLog:
2012-10-03 Dehao Chen
PR middle-end/54782
* tree-cfg.c
Hi,
This patch fixes the bug when comparing location to UNKNOWN_LOC.
Bootstrapped and passed gcc regression test.
Okay for trunk?
Thanks,
Dehao
2012-09-30 Dehao Chen
PR middle-end/54759
* gcc/tree-vect-loop-manip.c (slpeel_make_loop_iterate_ntimes): Use
LOCATION_LOCUS to compare with
Sorry to reply late, missed this mail again... not sure why.
LGTM, okay for google branches.
Dehao
On Mon, Sep 24, 2012 at 1:20 PM, Teresa Johnson wrote:
> Revised patch to add a new dump flag that dumps PMU profile information using
> the -pmu dump option. (Was issue 6489092, creating new issu
201 - 300 of 408 matches
Mail list logo
