T_PASS (pass_ipa_auto_profile);
NEXT_PASS (pass_ipa_free_inline_summary);
NEXT_PASS (pass_ipa_tree_profile);
PUSH_INSERT_PASSES_WITHIN (pass_ipa_tree_profile)
Index: gcc/debug.h
===
--- gcc/debug.h (revision 215826)
+++ gcc/debug.h (working copy)
@@ -
non-Intel 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
wrote:
> On 2014.10.20 at 14:21 -0700, Dehao Chen wrote:
>> >> +If @var{path} is sp
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
wrote:
> On 2014.10.21 at 13:53 -0700, Dehao Chen wrote:
>> Everything will be
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 wrote:
> Can someone pre-approve t
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
PR tree-optimization/61384
* tree-vrp.c (execute_vrp): rebuild frequency after vrp.
gcc/testsuite/ChangeLog:
2014-06-02
g on-going. OK for trunk if test pass?
>>
>> Thanks,
>> Dehao
>>
>> gcc/ChangeLog:
>> 2014-06-02 Dehao Chen
>>
>> PR tree-optimization/61384
>> * tree-vrp.c (execute_vrp): rebuild frequency after vrp.
>>
>> gcc/te
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 wrote:
> On 06/02/14 10:17, Dehao Chen wrote:
>>
>> We need to rebuild frequency after vrp, otherwise the following
ping...
Dehao
On Fri, May 30, 2014 at 4:13 PM, Dehao Chen 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%
On Wed, Jun 11, 2014 at 10:38 AM, Cary Coutant 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% 0.00%
k for Google/4_8?
>
> Teresa
>
> 2014-06-12 Teresa Johnson
> Dehao Chen
>
> Google ref b/15521327.
>
> * cgraphclones.c (cgraph_clone_edge): Use resolved node.
> * l-ipo.c (resolve_cgraph_node): Resolve to non
OK for google-4_8 and google-4_9
Thanks,
Dehao
On Tue, Jun 24, 2014 at 3:09 PM, Yi Yang 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 pave the way f
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 wrote:
>
> I refactored the code and added comments. A bug (prematurely breaking
> from a loop) was fixed during the refactoring.
>
> (My last mail was wrong
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 wrote:
> Fixed.
>
> Also, I spotted some warnings caused by me using "%lf"s in snprintf().
> I changed these to "%f" and tested.
>
>
>
an enough. I don't see a reason to intentionally drop precision
>>> though.
>>>
>>> Note 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 cau
0, 2014 at 5:41 PM, Yi Yang wrote:
>>> Done.
>>>
>>> On Mon, Jun 30, 2014 at 5:20 PM, Dehao Chen wrote:
>>>> For get_locus_information, can you cal get_inline_stack and directly use
>>>> its
>>>> output to
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
this case, recomputing inline summary does not help because the
code was bloated in first einline phase.
Dehao
>
> David
>
> On Thu, Nov 13, 2014 at 2:48 PM, Xinliang David Li wrote:
>> Is there a need to have 10 iterations of early inline for autofdo?
>>
>> David
>>
&
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 wrote:
> On Thu, Nov 13, 2014 at 2:57 PM, Dehao Chen wrote:
>> IIRC, AutoFDO the actual iteration for AutoFDO is mostly &
(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 wrote:
>
rkaround needed for the mainline autofdo version too?
>
> -Andi
>>
>> David
>>
>>
>> On Mon, Nov 17, 2014 at 12:47 PM, Dehao Chen 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
* auto-profile.c (afdo_annotate_cfg): Invoke update_ssa in the right
place
ok.
Dehao
On Mon, Feb 23, 2015 at 11:02 AM, Cary Coutant wrote:
> Minor changes to -ftwo-level-line-tables.
>
> This patch is for the google/gcc-4_9 branch.
>
> Originally, -ftwo-level-line-tables would output .subprog directives
> only for inlined subprograms, and not for non-inlined ones. This
On Tue, Mar 3, 2015 at 11:25 AM, Cary Coutant wrote:
> This patch is for the google/gcc-4_9 branch.
>
> With this patch, we output an empty name for non-inlined functions,
> and change the -ftwo-level-all-subprogs option to override this
> behavior to output linkage names instead. The consumer can
ok for google branch.
Dehao
On Tue, Mar 3, 2015 at 12:26 PM, Cary Coutant wrote:
>>> @@ -21817,22 +21823,39 @@ out_subprog_directive (subprog_entry *su
>>> {
>>>tree decl = subprog->decl;
>>>tree decl_name = DECL_NAME (decl);
>>> - const char *name;
>>> + tree origin;
>>
>> Explicitly
. Any comments?
Bootstrapped and test on-going.
OK for trunk?
Thanks,
Dehao
ChangeLog:
2015-06-23 Dehao Chen
* opts.c(finish_options): Disable reorder_blocks_and_partition for DWARF2.
Index: opts.c
===
--- opts.c (revision 2
On Sun, Jan 25, 2015 at 6:06 PM, Cary Coutant wrote:
> Add -ftwo-level-line-tables and -gline-tables-only options.
>
> With -ftwo-level-line-tables, GCC will generate two-level line tables,
> which adds inline call information to the line tables, obviating the
> need to keep bulky debug info aroun
On Wed, Jan 28, 2015 at 3:04 PM, Cary Coutant wrote:
>
> >> +static subprog_entry *
> >> +add_subprog_entry (tree decl, bool is_inlined)
> >> +{
> >> + subprog_entry **slot;
> >> + subprog_entry *entry;
> >> +
> >> + slot = subprog_table->find_slot_with_hash (decl, DECL_UID (decl),
> >> INSERT
On Wed, Jan 28, 2015 at 4:34 PM, Cary Coutant wrote:
>>> > Not quite clear why we need block_table. This table is not gonna be
>>> > emitted. And we can easily get subprog_entry through block->block_num
>>>
>>> When final_scan_insn() calls dwarf2out_begin_block(), all it passes is
>>> a block numb
patch is ok for google branch.
Dehao
On Thu, Jan 29, 2015 at 1:11 PM, Cary Coutant wrote:
> Here's a very slightly revised patch, fixing a couple of bugs found
> during GDB testing.
>
> In out_logical_entry, I should pass along the value of is_stmt when
> creating a logical for the calling conte
The offset overflow warning would cause build fails when function's
start line is missing(0). Until the start line issues is fixed, we
will suppress this warning.
Testing on-going. OK for google-4_9?
Thanks,
Dehao
Index: gcc/auto-profile.c
===
. Free Software Foundation, Inc.
Contributed by Dehao Chen (de...@google.com)
This file is part of GCC.
@@ -18,19 +18,17 @@ You should have received a copy of the GNU General
along with GCC; see the file COPYING3. If not see
<http://www.gnu.org/licenses/>. */
-/* Read and annotate call
This patch fixes the bug for undefined symbol in AutoFDO build.
Testing on going. OK for google-4_9 branch?
Thanks,
Dehao
Index: gcc/auto-profile.c
===
--- gcc/auto-profile.c (revision 218784)
+++ gcc/auto-profile.c (working copy)
@
ping...
Thanks,
Dehao
On Tue, Nov 18, 2014 at 2:29 PM, Dehao Chen wrote:
> 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:
promote the
indirect call anyway.
Dehao
On Tue, Dec 16, 2014 at 2:45 PM, Xinliang David Li wrote:
> Does it paper over the real bug?
>
> David
>
> On Tue, Dec 16, 2014 at 2:38 PM, Dehao Chen wrote:
>> This patch fixes the bug for undefined symbol in AutoFDO build.
>>
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
.
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
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
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
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
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
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
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
> 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
> 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
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
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.
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
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
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 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
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 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
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
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
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
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 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
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
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
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
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 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.
;
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
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
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
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
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
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
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
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
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
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
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
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
===
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
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
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
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 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 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 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
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
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
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
> ===
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
Sure, will update the patch for that.
Dehao
On Wed, May 22, 2013 at 9:40 AM, Cary Coutant wrote:
> @@ -105,7 +105,7 @@ struct locus_descrim_hasher : typed_free_remove inline hashval_t
> locus_descrim_hasher::hash (const value_type *item)
> {
> - return item->locus;
> + return LOCATION_LINE
ChangeLog fix patch committed in r199394.
The attached patch restricts the test only run on linux-gnu targets. Is it ok?
Thanks
Dehao
gcc/ChangeLog:
2013-05-28 Dehao Chen
testsuite/debug/dwarf2/discriminator.c: Restrict the test to linux only.
Index: gcc/testsuite/gcc.dg/debug/dwarf2
Patch updated and committed as r199412.
Thanks,
Dehao
In gcc4-8, the max einline iterations are restricted to 1. For
AutoFDO, this is bad because early inline is not size restricted. This
patch allows einline to do multiple iterations in AutoFDO. It also
enables tracer optimization in AutoFDO.
Bootstrapped and passed regression test.
OK for googel-4
that should be common to
> FDO/LIPO).
>
> David
>
> On Wed, May 29, 2013 at 9:39 AM, Dehao Chen wrote:
>> In gcc4-8, the max einline iterations are restricted to 1. For
>> AutoFDO, this is bad because early inline is not size restricted. This
>> patch allows einlin
On Thu, May 30, 2013 at 1:40 AM, Andreas Schwab wrote:
> Rainer Orth writes:
>
>> And why do you add -gdwarf-2 in dg-options? AFAICS all tests in
>> gcc.dg/debug/dwarf2 are built with -gdwarf-2 anyway.
>
> Do they? Not here.
>
> Executing on host: /daten/aranym/gcc/gcc-20130530/Build/gcc/xgcc
On Thu, May 30, 2013 at 10:41 AM, Cary Coutant wrote:
>> That's weird cause in dwarf2.exp:
>>
>> # If a testcase doesn't have special options, use these.
>> global DEFAULT_CFLAGS
>> if ![info exists DEFAULT_CFLAGS] then {
>> set DEFAULT_CFLAGS " -ansi -pedantic-errors -gdwarf-2"
>> }
>>
>> But
This patch makes more strict check of call args to make sure the
number of args match.
Bootstrapped and passed regression tests.
OK for google branches?
Thanks,
Dehao
Index: gcc/gimple-low.c
===
--- gcc/gimple-low.c (revision 19941
return false;
}
+ if (p != NULL)
+ return false;
}
else if (parms)
{
On Thu, May 30, 2013 at 4:10 PM, Xinliang David Li wrote:
> On Thu, May 30, 2013 at 3:47 PM, Dehao Chen wrote:
>> This patch makes more strict check of call args to make sure the
>&g
assed regression test.
OK for trunk?
Thanks,
Dehao
libcpp/ChangeLog:
2013-05-31 Dehao Chen
* files.c (_cpp_stack_include): Fix the highest_location when header
file is guarded by #ifndef and is included twice.
Index: libcpp/fi
This patch fixes an uninitialized memory error and a hashtable
comparison bug in AutoFDO.
Bootstrapped and passed regression test.
OK for google branches?
Thanks,
Dehao
Index: gcc/auto-profile.c
===
--- gcc/auto-profile.c (revision
testing on-going...
Dehao
On Wed, May 29, 2013 at 3:44 PM, Dehao Chen wrote:
> OK, I'll commit the early inline part.
>
> Dehao
>
> On Wed, May 29, 2013 at 10:00 AM, Xinliang David Li
> wrote:
>> The early inlining part is ok. The tracer optimization sho
or at most, say 10, iterations.
Dehao
>
> David
>
> On Sun, Jun 2, 2013 at 6:21 PM, Dehao Chen wrote:
> > The patch was committed to google-4_8, but it causes problem because
> > einline sets PARAM_EARLY_INLINING_INSNS = 11. This will cause
> > recursive inlining at einli
e:
> If the purpose of the fix is to filter early inlinings with code
> growth in autoFDO, the proposed fix is the wrong way to do -- it
> changes the meaning of cgraph_maybe_hot_edge_p.
>
> David
>
> On Sun, Jun 2, 2013 at 7:25 PM, Dehao Chen wrote:
>> On Sun, Jun 2, 2013
David Li wrote:
> The patch is ok if performance test passes. For a complete fix, Is it
> better to tune down PARAM_EARLY_INLINE_INSNS from 11 to a small value
> for autoFDO or use a different parameter?
>
> David
>
> On Sun, Jun 2, 2013 at 9:19 PM, Dehao Chen wrote:
>>
101 - 200 of 408 matches
Mail list logo
