ok for google branches.
David
On Fri, Mar 9, 2012 at 10:59 AM, Rong Xu wrote:
> Hi,
>
> This patch is for google branches only.
>
> It saves -std=* option to lipo profile so that non-c99 primary module
> can include c99 auxiliay modules with restrict keyword.
>
> Tested with bootstrap and google
ok. As Ollie said, it needs to be in google/gcc-4_7 as well.
David
On Mon, Mar 12, 2012 at 6:03 PM, Easwaran Raman wrote:
> This patch makes -fsized-delete define a macro __GXX_DELETE_WITH_SIZE__. If
> this macro is defined, the deallocate function in new_allocator.h invokes
> the two parameter
On Tue, Mar 13, 2012 at 11:56 AM, Cary Coutant wrote:
>>> I, for one, welcome our new nuclear overlords.
>>
>> AFAICS the internal switch is called dwarf_split_debug_info so a short
>> moniker
>> based on it would be more understandable (and avoid a useless pomposity).
>
> I wasn't trying to be p
thanks. This greatly improves the usability of the plugin based
function reordering feature and is in a shape that can be pushed to
trunk.
Regarding the sub-options, cgedge does not seem user friendly. How
about just -freorder-functions=callgraph or
-freorder-function=clustering?
What is the inte
ok.
thanks,
David
On Wed, Mar 21, 2012 at 11:20 AM, Sriraman Tallam wrote:
> Hi,
>
> I am bumping up the default param value of function size limit for
> auto cloning. Since auto cloning happens on inlined functions, the
> original value does not catch some cases in one of our benchmarks.
>
>
Ok for google branches (main and 4_7).
thanks,
David
On Wed, Mar 21, 2012 at 2:45 PM, Harshit Chopra wrote:
> 2012-03-21 Harshit Chopra
>
> Minor changes:
> i386.c: made check_should_patch_current_function C90 compatible.
> i386.md: Added '\t' to bytes generated by
> ix86
Can the test case be improved so that expected prediction results is
checked (with the help of more dumping such as blah blah is predicted
to be taken/not taken with probability xyz) ?
Also the more test cases need to be added to cover more cases >base, >
base +1, >=base +2, < base+1, <=base+1 etc
e. */
> + predict_edge_def (then_edge, PRED_LOOP_IV_COMPARE, NOT_TAKEN);
> + }
> + else if (expr_coherent_p (loop_iv_base_var, compare_var))
> + {
> + /* For cases like:
> + for (i = s; i < h; i++)
> + if (i > s + 2)
> + The b
ok for google branches
David
On Wed, Apr 4, 2012 at 8:56 PM, wrote:
> Reviewers: Diego Novillo, jingyu, davidxl,
>
> Message:
> Please take a look at this patch and tell me if it's OK for
> branches/google/gcc-4_6.
>
> Description:
> Backported the following patch from trunk:
>
> 2011-10-07 An
Hi Richard, this is a follow up patch for more cleanups.
Bootstrap and tested on x86-64/linux.
Ok for trunk?
thanks,
David
todo_dump.p
Description: Binary data
cg
Description: Binary data
cc Richard.
thanks,
David
On Mon, Apr 16, 2012 at 3:24 AM, Rainer Orth
wrote:
> As reported in PR testsuite/52948, several plugin testcases were failing
> since the removal of TODO_dump_func:
>
> UNRESOLVED: selfassign.c compilation, -I.
> -I/vol/gcc/src/hg/trunk/local/gcc/testsuite
> -I/vol/
On Tue, Apr 17, 2012 at 1:48 AM, Jan Hubicka wrote:
>> > Note that it would make a lot of sense to teach this heuristics predict.c
>> > and properly identify chars.
>>
>> Indeed this would be the proper place to implement this logic.
>
> TO a degree - switch expansion needs more info than it can o
ok.
David
On Tue, Apr 17, 2012 at 11:40 AM, Teresa Johnson wrote:
> I have a patch to fix a compile time warning about an unused variable due
> to the use being guarded by #ifndef __GCOV_KERNEL__.
>
> Tested with bootstrap. Ok for google-main?
>
> Teresa
>
> 2012-04-17 Teresa Johnson
>
>
Why only rtl? Minor suggestion: use ir or il may be more intuitive:
-fdump-rtl-all-ir
thanks,
David
On Wed, Apr 18, 2012 at 9:35 AM, Andrew Stubbs wrote:
> This patch scratches an itch I've had for a while.
>
> Basically it just reduces all tree and RTL dumps to just the function dump.
> This m
On Wed, Apr 18, 2012 at 12:42 PM, Andrew Stubbs wrote:
> On 18/04/12 19:00, Xinliang David Li wrote:
>>
>> Why only rtl? Minor suggestion: use ir or il may be more intuitive:
>> -fdump-rtl-all-ir
>
>
> It isn't only RTL. It also applies to the tree dumps. I d
On Thu, Apr 19, 2012 at 5:58 AM, Andrew Stubbs wrote:
> On 18/04/12 22:09, Xinliang David Li wrote:
>>
>> Flags in category 1)
>> --
>> There are four types of information that can be dumped (should be
>> controlled by flag set 1) ):
&
Compiling the attached test case with -O2 using the trunk compiler,
the compiler will ICE. The proposed patch is also attached. The test
is under going, but I like to have discussion on the right fix first.
thanks,
David
Analysis:
-
Here is what is happening:
BB6 : (Successor: BB8)
On Fri, Apr 20, 2012 at 4:50 AM, Richard Guenther
wrote:
> On Fri, Apr 20, 2012 at 12:07 PM, Richard Guenther
> wrote:
>> On Fri, Apr 20, 2012 at 10:41 AM, Richard Guenther
>> wrote:
>>> On Thu, Apr 19, 2012 at 8:51 PM, Xinliang David Li
>>> wrote:
>&g
On Fri, Apr 20, 2012 at 3:07 AM, Richard Guenther
wrote:
> On Fri, Apr 20, 2012 at 10:41 AM, Richard Guenther
> wrote:
>> On Thu, Apr 19, 2012 at 8:51 PM, Xinliang David Li
>> wrote:
>>> Compiling the attached test case with -O2 using the trunk compiler,
>>>
ok.
thanks,
David
On Fri, Apr 20, 2012 at 2:13 PM, Rong Xu wrote:
> Hi,
>
> This patch is for google-4_6 branch only.
>
> It disables the localization of hidden and internal symbols in streaming
> LIPO. Otherwise, we may have undefines in link time because of the reference
> in
> other module
On Tue, Apr 24, 2012 at 6:13 PM, Andi Kleen wrote:
> tejohn...@google.com (Teresa Johnson) writes:
>
>> This patch adds heuristics to limit unrolling in loops with branches that
>> may increase
>> branch mispredictions. It affects loops that are not frequently iterated,
>> and that are
>> nested
I think the general mechanism applies to most of the targets. What is
needed is target specific parameter (branch budget) tuning which can
be done separately -- there exist a way to do that already.
David
On Wed, Apr 25, 2012 at 2:03 AM, Richard Guenther
wrote:
> On Tue, Apr 24, 2012 at 11:26 PM
ok.
David
On Wed, Apr 25, 2012 at 1:08 PM, Rong Xu wrote:
> Hi,
>
> This patch is for google-4_6 branch only.
> It fixes the broken -S in streaming LIPO mode.
>
> Tested with bootstrap.
>
> Thanks,
>
> 2012-04-25 Rong Xu
>
> * gcc/gcc.c (ripa_lto_spec): Support -S.
> (cc1_optio
Ping ..
David
On Tue, Dec 27, 2011 at 10:46 AM, Xinliang David Li wrote:
> Ping ..
>
> On Fri, Dec 9, 2011 at 9:42 AM, Xinliang David Li wrote:
>> Ping ..
>>
>> On Wed, Dec 7, 2011 at 4:01 PM, Xinliang David Li wrote:
>>> Build the test case in the patch f
Ok for google/main after compiler bootstrap and regression test
(without ftsan), and some large tests with tsan turned on (as many as
you can but at your discretion).
David
On Sun, Nov 13, 2011 at 11:59 PM, wrote:
> On 2011/11/11 00:00:35, davidxl wrote:
>>
>> Have you run through SPEC, and SPE
The failures are independent which will be looked into at some point.
Teresa's patch is/will be tested cleanly on google-46.
David
On Tue, Nov 22, 2011 at 1:12 PM, Diego Novillo wrote:
> On 11-11-22 16:06 , Teresa Johnson wrote:
>>
>> This patch is for google-main only.
>> Tested with bootstrap
Ok for google branches.
David
On Tue, Nov 22, 2011 at 1:06 PM, Teresa Johnson wrote:
> This patch is for google-main only.
> Tested with bootstrap and regression tests.
> Under LIPO, estimate the code size footprint from the partial call
> graph, and if it is large limit unrolling and peeling to
ok for google branches.
David
On Wed, Nov 30, 2011 at 6:09 AM, wrote:
> On 2011/11/30 13:17:04, Diego Novillo wrote:
>>
>> On 11-11-30 03:53 , mailto:dvyu...@google.com wrote:
>> > On 2011/11/14 16:48:45, davidxl wrote:
>> >> Ok for google/main after compiler bootstrap and regression test
>> >>
;
>
> +/* Determine whether LOOP contains floating-point computation. */
> +bool
> +loop_has_FP_comp(struct loop *loop)
> +{
> + rtx set, dest;
This probably should be extended to detect other long latency
operations in the future.
> +
> + if (ix86_tune != PROCESSOR_COREI7_64 &&
> + ix86_
On Fri, Dec 2, 2011 at 11:36 AM, Andi Kleen wrote:
> Teresa Johnson writes:
>
> Interesting optimization. I would be concerned a little bit
> about compile time, does it make a measurable difference?
>
>> The attached patch detects loops containing instructions that tend to
>> incur high LCP (loo
ok for google/main.
David
On Wed, Dec 7, 2011 at 3:04 AM, wrote:
> On 2011/12/05 17:05:17, dvyukov wrote:
>>
>> This is for google-main branch.
>> Fix taking address of SSA_NAME in ThreadSanitizer pass.
>
>
>> Index: gcc/tree-tsan.c
>> ===
Build the test case in the patch file with -finstrument-functions, the
link will fail with unsat. The problem is gcc instruments the
artificial wrappers that will won't be emitted. The patch fixes the
problem. Bootstrap and tested on x86-64/linux.
Ok for mainline?
thanks,
David
Index: gimplify.c
On Wed, Dec 7, 2011 at 4:25 PM, Andrew Pinski wrote:
> On Wed, Dec 7, 2011 at 4:01 PM, Xinliang David Li wrote:
>> Build the test case in the patch file with -finstrument-functions, the
>> link will fail with unsat. The problem is gcc instruments the
>> artificial wrappe
Ping ..
On Wed, Dec 7, 2011 at 4:01 PM, Xinliang David Li wrote:
> Build the test case in the patch file with -finstrument-functions, the
> link will fail with unsat. The problem is gcc instruments the
> artificial wrappers that will won't be emitted. The patch fixes the
> probl
The patch is good for google branches for now while waiting for upstream review.
David
On Sun, Dec 4, 2011 at 10:26 PM, Teresa Johnson wrote:
> Latest patch which improves the efficiency as described below is
> included here. Boostrapped and checked again with
> x86_64-unknown-linux-gnu. Could s
> +/* Returns true if the vector load/store is unaligned and if
> + unaligned vector load/stores are slow. */
document STMT.
>
> +static bool
> +is_slow_vect_unaligned_load_store (gimple stmt)
> +{
> + stmt_vec_info stmt_info;
> + struct data_reference *dr = NULL;
> +
> + /* Are unaligned l
See instruction tables here:
http://www.agner.org/optimize/instruction_tables.pdf
My brief reading of the table for core2 and corei7 suggest the following:
1. On core2
movdqu -- both load and store forms take up to 8 cycles to complete,
and store form produces 8 uops while load produces 4 uops
There are a couple of problems with the patch (the patch is only
compatible with 4_6 branch)
1) the dump_inline_decision should be called inside
cgraph_mark_inline_edge when the edge is finally picked (and when the
callee node is cloned)
2) The source location is not printed which makes the dumpin
The patch is ok for google branches for now.
David
On Tue, Dec 13, 2011 at 4:33 PM, wrote:
> On 2011/12/14 00:04:10, davidxl wrote:
>>
>> http://codereview.appspot.com/5488054/diff/4002/tree-vect-stmts.c
>> File tree-vect-stmts.c (right):
>
>
>
> http://codereview.appspot.com/5488054/diff/4002/
.
David
On Tue, Dec 13, 2011 at 11:18 PM, Xinliang David Li wrote:
> There are a couple of problems with the patch (the patch is only
> compatible with 4_6 branch)
>
> 1) the dump_inline_decision should be called inside
> cgraph_mark_inline_edge when the edge is finally picke
the bfd_name, which is much shorter for C++ symbols.
>
> Thanks,
> Dehao
>
> On Thu, Dec 15, 2011 at 2:07 AM, Xinliang David Li wrote:
>> Another usability related issue for C++. The long demangled function
>> names will make the info messages very hard to swallow. Since th
Ok for google branches -- not applicable to trunk.
David
On Fri, Dec 16, 2011 at 2:37 PM, Rong Xu wrote:
> Hi,
>
> This patch fixes the insane values in runs and run_max field of the
> program summary. This can happen when the gcda files manually removed
> from the output directory after the mer
ok for google branches.
David
On Fri, Dec 16, 2011 at 7:54 PM, Sriraman Tallam wrote:
> Add new target builtins __builtin_cpu_is_intel_corei7 and
> __builtin_cpu_is_amdfam10.
>
> * config/i386/i386-cpuinfo.c (__processor_model): Add new members
> __cpu_is_intel_corei7 and __cpu_is_
ok for google branches.
David
On Fri, Dec 16, 2011 at 2:05 PM, wrote:
> I have uploaded a new patch set with all the mentioned changes made. If
> a function has the target attribute it will not be touched by the
> autoclone pass.
>
> Also fixed some test cases which were broken because the clon
ok.
David
On Sat, Dec 17, 2011 at 11:44 AM, Easwaran Raman wrote:
> Based on Paolo's comments I am dropping the changes to
> baseline_symbols.txt. As far as minor version, I am bumping it up to
> 18. Assuming that this patch will be able to go in gcc 4.8 (with minor
> version 18), I want to keep
ok for google branches
David
On Wed, Dec 21, 2011 at 4:12 PM, Rong Xu wrote:
> This patch is for google_main branch only.
>
> This patch fixes the ICE when using LIPO profiles for regular FDO
> compilation. LIPO has INDIR_CALL_TOPN profiles while FDO has
> INDIR_CALL profile.
>
> Tested with SPE
Ok for google branches when tests are done. Update ChangeLog file properly.
David
On Tue, Dec 20, 2011 at 1:55 PM, Harshit Chopra wrote:
>
>
> On Fri, Dec 16, 2011 at 3:10 PM, wrote:
>>
>> Ok, Cary's explanation makes sense. Please update the comments to make
>> it clearer.
>>
>>
>>
>> http://c
Ping ..
On Fri, Dec 9, 2011 at 9:42 AM, Xinliang David Li wrote:
> Ping ..
>
> On Wed, Dec 7, 2011 at 4:01 PM, Xinliang David Li wrote:
>> Build the test case in the patch file with -finstrument-functions, the
>> link will fail with unsat. The problem is gcc instrume
the early inline decisions are still good to dump out. However the
opt-info should check 'if (profile_info)' to decide if count and max
count info need to be dumped.
David
On Fri, Dec 30, 2011 at 12:31 AM, Dehao Chen wrote:
> Hi,
>
> This patch makes the -fopt-info print more concise info:
> 1.
pt_info >= OPT_INFO_MED && profile_info)
> + sprintf (buf, "("HOST_WIDEST_INT_PRINT_DEC",
> "HOST_WIDEST_INT_PRINT_DEC")",
> + node->count, node->max_bb_count);
> return buf;
> }
>
> On Fri, Dec 30, 2011 at 4:59 PM,
Is there a better way to detect early inline phase and ipa_inline
pass? Use always_inline_functions_inlined flag seems hacky.
David
On Wed, Jan 4, 2012 at 1:12 AM, Dehao Chen wrote:
> Hi,
>
> This patch:
>
> * dump inline decisions with profile info whenever available.
> * disable dump of einlin
Not ideal but better. Ok with this change.
David
On Thu, Jan 5, 2012 at 5:47 PM, Dehao Chen wrote:
> Or use a new global variable to denote whether it's in early-inline or
> ipa-inline?
>
> Dehao
>
> On Fri, Jan 6, 2012 at 1:46 AM, Xinliang David Li wrote:
>>
>&
o != NULL)
> inline_chain_text = cgraph_node_call_chain (final_caller, &final_caller);
> else
> @@ -1193,6 +1198,8 @@
> int min_size, max_size;
> VEC (cgraph_edge_p, heap) *new_indirect_edges = NULL;
>
> + is_in_ipa_inline = true;
> +
> if (flag_indirect_inlining)
It looks non-ambiguous to me.
David
On Mon, Jan 9, 2012 at 1:05 AM, Richard Guenther wrote:
>
> Since GCC 4.4 applying the malloc attribute to realloc-like
> functions does not work under the documented constraints because
> the contents of the memory pointed to are not properly transfered
> fro
of course your new version.
thanks,
David
On Tue, Jan 10, 2012 at 1:31 AM, Richard Guenther wrote:
> On Mon, 9 Jan 2012, Xinliang David Li wrote:
>
>> It looks non-ambiguous to me.
>
> The new proposed version or the old?
>
> Richard.
>
>> David
>>
>
Good for google branches.
Please re-submit the combined runtime support patch to trunk for review.
thanks,
David
On Wed, Jan 11, 2012 at 12:06 PM, wrote:
> New patch uploaded with the changes.
>
>
> * i386.c (IX86_BUILTIN_CPU_IS_AMDFAM15H_BDVER1): New enum value.
> (IX86_BUILTIN
ok for google branches.
David
On Wed, Jan 11, 2012 at 2:55 PM, Rong Xu wrote:
> This patch fixes the ICE when building the histrogram for
> value profile. It's casued by profile mismatch.
>
> Tested with SPEC2000 INT.
>
> This is for google branches.
>
> 2012-01-11 Rong Xu
>
> * gcc/p
Nathan, I just noticed this path. This is a good improvement over the
existing scheme.
I see one potential problem with the patch -- different instances of
the same comdat function can potentially have different control flows
(due to differences in early inline, early optimizations in different
mo
odule (the final defining module of the comdat).
Am I missing something?
thanks,
David
On Fri, Jan 20, 2012 at 2:41 PM, Xinliang David Li wrote:
> Nathan, I just noticed this path. This is a good improvement over the
> existing scheme.
>
> I see one potential problem with the p
On Mon, Jan 23, 2012 at 12:52 PM, Nathan Sidwell wrote:
> On 01/20/12 22:41, Xinliang David Li wrote:
>>
>> Nathan, I just noticed this path. This is a good improvement over the
>> existing scheme.
>>
>> I see one potential problem with the patch -- differen
Ok for google branch with minor changes below.
thanks,
David
>> +static bool non_zero_profile_counts ( VEC(edge,gc) *edges) {
static bool
non_zero_profile_counts(...)
Please also provide function documentation.
>> + edge e;
>> + edge_iterator ei;
>> + FOR_EACH_EDGE(e, ei, edges)
>> + {
ok.
thanks,
David
On Wed, Feb 1, 2012 at 7:33 AM, Dehao Chen wrote:
> There are still some minor bugs in the current implementation, which
> is fixed by the attached patch:
>
> passed bootstrap/regression tests for both google-4_6 and google-main branch.
>
> ok for google branch?
>
> Thanks,
>
thanks. ok for google/gcc_46 branch.
David
On Wed, Feb 1, 2012 at 11:52 AM, Easwaran Raman wrote:
> On Tue, Jan 31, 2012 at 10:16 PM, Xinliang David Li
> wrote:
>> Ok for google branch with minor changes below.
>>
>> thanks,
>>
>> David
>>
>&
ok for google branches.
David
On Thu, Feb 2, 2012 at 2:30 PM, Rong Xu wrote:
> Hi,
>
> This patch curbs the counter scaling factor that causing counter
> overflow in inline transformation. The negavie counter triggers
> a later pass assertion.
>
> Tested: inertnal performance benchmarks.
>
> -Ro
This code before the change seems to over-estimate the number of real
nodes which should be safe -- can you explain why it causes problem?
David
On Thu, Feb 2, 2012 at 6:13 PM, Sriraman Tallam wrote:
> Fix a bug in the function reordering linker plugin where the number of nodes
> to be reordered
. Hence, this is safe.
>
> Thanks,
> -Sri.
>
>
>
> On Thu, Feb 2, 2012 at 8:23 PM, Xinliang David Li wrote:
>> This code before the change seems to over-estimate the number of real
>> nodes which should be safe -- can you explain why it causes problem?
>>
>
ok for google branches.
David
On Fri, Feb 3, 2012 at 3:20 PM, Harshit Chopra wrote:
> Fixes the following tests by restricting them to 64-bit target environment.
>
> Tested: Using 'make -k check-gcc RUNTESTFLAGS="i386.exp=patch*
> --target_board=unix\{-m32,,-m64\}"' and crosstool-validate.py sc
ok.
On Tue, Feb 14, 2012 at 11:34 AM, Jing Yu wrote:
> arm-eabi toolchain needs GNU-stack note for security purpose.
> Will Keep this patch in google branches.
>
> OK for google/main?
> I would like to port this patch to google/gcc-4_6, google/gcc-4_6-mobile,
> google/gcc-4_6_2-moible.
>
> 2012-0
ok. thanks,
David
On Tue, Feb 21, 2012 at 8:25 PM, Ollie Wild wrote:
> The latest Crosstool builds reveal one new test failure (and fix several
> others). This patch adds the missing failure to
> x86_64-unknown-linux-gnu.xfail.
>
> 2012-02-21 Ollie Wild
>
> * testsuite-management/x86
ok.
David
On Fri, Feb 24, 2012 at 4:19 PM, Sriraman Tallam wrote:
> function_reordering_plugin.c includes which is not available
> on non-ELF platforms building a cross-compiler. This patch checks for
> before including it. Otherwise, it redefines the macros used.
> This is safe because the ma
Sri, probably need to remove the [google] prefix in the subject line
to prevent this from being filtered.
David
On Thu, Mar 1, 2012 at 12:45 PM, Sriraman Tallam wrote:
> Patch to add builtins to detect CPU type:
>
>
> I have ported the patch from google/g
:
Size
Before: 1,175,509
After: 1,568,135
Change: +33.4%
Time
Before: 5.3s
After: 12.9s
Change: +143%
On Fri, May 20, 2011 at 8:53 AM, Xinliang David Li wrote:
> On Fri, May 20, 2011 at 2:12 AM, Richard Guenther
> wrote:
>> On Thu, May 19, 2011 at 8:26 PM, Xinliang David Li
>
Hi, the following trial patch fixed PR 48988 which is a regression.
Bootstrap and tested on x86/linux. Verified the reported failure is fixed.
Ok for trunk?
David
2011-05-22 David Li
PR tree-optimization/48988
* tree-ssa-uninit.c (convert_control_dep_chain_into_preds
Ping.
David
On Fri, May 20, 2011 at 9:06 AM, Xinliang David Li wrote:
> Ok to check in this one?
>
> Thanks,
>
> David
>
> On Wed, May 18, 2011 at 12:30 PM, Joseph S. Myers
> wrote:
>> On Wed, 18 May 2011, David Li wrote:
>>
>>> + error (&q
ok for google/main.
David
On Mon, May 23, 2011 at 2:06 PM, Rong Xu wrote:
> Add the initializtion for eof_pos. eof_pos may not be initialized properly
> when part of gcda files got merged.
>
> Tested with gcc bootstrap and regression tests.
>
> 2011-05-23 Rong Xu
>
> * gcc/libgcov.c (g
Ping. The link to the message:
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01303.html
Thanks,
David
On Sun, May 22, 2011 at 4:17 PM, Xinliang David Li wrote:
> Ping.
>
> David
>
>
> On Fri, May 20, 2011 at 9:06 AM, Xinliang David Li wrote:
>> Ok to check i
Fair enough. Richard?
Thanks,
David
On Wed, May 25, 2011 at 9:53 AM, Joseph S. Myers
wrote:
> On Wed, 25 May 2011, Xinliang David Li wrote:
>
>> Ping. The link to the message:
>>
>> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01303.html
>
> I don't con
On Thu, May 26, 2011 at 2:04 AM, Richard Guenther
wrote:
> On Wed, May 25, 2011 at 6:53 PM, Joseph S. Myers
> wrote:
>> On Wed, 25 May 2011, Xinliang David Li wrote:
>>
>>> Ping. The link to the message:
>>>
>>> http://gcc.gnu.org/ml/gcc-patches/2011
The latest version that only exports 2 functions from passes.c.
David
On Thu, May 26, 2011 at 2:04 PM, Xinliang David Li wrote:
> On Thu, May 26, 2011 at 2:04 AM, Richard Guenther
> wrote:
>> On Wed, May 25, 2011 at 6:53 PM, Joseph S. Myers
>> wrote:
>>> On Wed, 25
e_ipa' into 'profile', and make 'ipa_profile' and
'profile' into 'profile_estimate'. The rest of cleanups are needed to
make sure pass names are unique.
Ok for trunk?
Thanks,
David
On Fri, May 27, 2011 at 2:58 AM, Richard Guenther
wrote:
> On Fri,
Committed.
David
This is the complete patch for pass name fixes (with test case changes).
David
On Mon, May 30, 2011 at 1:16 PM, Xinliang David Li wrote:
> The attached are two simple follow up patches
>
> 1) the first patch does some refactorization on function header
> dumping (with more informa
On Tue, May 31, 2011 at 2:05 AM, Richard Guenther
wrote:
> On Mon, May 30, 2011 at 10:16 PM, Xinliang David Li
> wrote:
>> The attached are two simple follow up patches
>>
>> 1) the first patch does some refactorization on function header
>> dumping (with more inf
ned on/off anyway.
The patch also enhanced -fenable-xxx and -fdisable-xx to allow a list
of function assembler names to be specified.
Ok for trunk?
Thanks,
David
out
Description: Binary data
2011-05-31 David Li
* passes.c (passr_eq):
(register_pass_name): Change pass name table name.
(get_pa
The new patch is attached. The test (c,c++,fortran, java, ada) is on going.
Thanks,
David
On Tue, May 31, 2011 at 9:06 AM, Xinliang David Li wrote:
> On Tue, May 31, 2011 at 2:05 AM, Richard Guenther
> wrote:
>> On Mon, May 30, 2011 at 10:16 PM, Xinliang David Li
>> wrote
Honza, are you ok with the pass name change?
David
On Tue, May 31, 2011 at 2:07 AM, Richard Guenther
wrote:
> On Mon, May 30, 2011 at 11:44 PM, Xinliang David Li
> wrote:
>> This is the complete patch for pass name fixes (with test case changes).
>
> This is ok if Honza
Please discard the previous one. This is the right one:
David
On Tue, May 31, 2011 at 5:01 PM, Xinliang David Li wrote:
> The new patch is attached. The test (c,c++,fortran, java, ada) is on going.
>
> Thanks,
>
> David
>
> On Tue, May 31, 2011 at 9:06 AM, Xinliang David
On Wed, Jun 1, 2011 at 1:51 AM, Richard Guenther
wrote:
> On Wed, Jun 1, 2011 at 1:34 AM, Xinliang David Li wrote:
>> The following patch implements the a new option that dumps gcc PASS
>> configuration. The sample output is attached. There is one
>> limitation: some placeh
The attached is the split #1 patch that enhances -fenable/disable.
Ok after testing?
Thanks,
David
On Wed, Jun 1, 2011 at 9:16 AM, Xinliang David Li wrote:
> On Wed, Jun 1, 2011 at 1:51 AM, Richard Guenther
> wrote:
>> On Wed, Jun 1, 2011 at 1:34 AM, Xinliang David Li wr
The attached is patch-2 (-fdump-passes) and a sample output:
Ok for trunk?
David
On Wed, Jun 1, 2011 at 9:16 AM, Xinliang David Li wrote:
> On Wed, Jun 1, 2011 at 1:51 AM, Richard Guenther
> wrote:
>> On Wed, Jun 1, 2011 at 1:34 AM, Xinliang David Li wrote:
>>> The follo
On Wed, Jun 1, 2011 at 12:29 PM, Richard Guenther
wrote:
> On Wed, Jun 1, 2011 at 6:16 PM, Xinliang David Li wrote:
>> On Wed, Jun 1, 2011 at 1:51 AM, Richard Guenther
>> wrote:
>>> On Wed, Jun 1, 2011 at 1:34 AM, Xinliang David Li
>>> wrote:
>>>
Hi, this is a simple patch that support dump_before flag. E.g,
-fdump-tree-pre-before
This is useful for diffing the the IR before and after a pass.
Gcc dumping needs more cleanups -- such as allowing IR only dump,
allowing IR dumping for a particular function etc. The exposure of
'dumpfile' (in
Sorry about it. Here it is.
David
On Wed, Jun 1, 2011 at 1:36 PM, Richard Guenther
wrote:
> On Wed, Jun 1, 2011 at 10:26 PM, Xinliang David Li wrote:
>> Hi, this is a simple patch that support dump_before flag. E.g,
>>
>> -fdump-tree-pre-before
>>
>> This
On Wed, Jun 1, 2011 at 2:12 PM, Basile Starynkevitch
wrote:
> On Wed, 1 Jun 2011 13:26:24 -0700
> Xinliang David Li wrote:
>
>> Hi, this is a simple patch that support dump_before flag. E.g,
>>
>> -fdump-tree-pre-before
>>
>> This is useful for dif
This is the version of the patch that walks through pass lists.
Ok with this one?
David
On Wed, Jun 1, 2011 at 12:45 PM, Xinliang David Li wrote:
> On Wed, Jun 1, 2011 at 12:29 PM, Richard Guenther
> wrote:
>> On Wed, Jun 1, 2011 at 6:16 PM, Xinliang David Li wrote:
>>>
Smoothing works for sample FDO and profile data from multi-threaded
programs. You won't see any difference in SPEC.
David
On Thu, Jun 2, 2011 at 11:00 AM, Martin Thuresson wrote:
> This patch from Neil Vachharajani and Dehao Chen improves mcf by using
> minimum cost circulation instead of minimu
ok for google/main.
David
On Thu, Jun 2, 2011 at 11:00 AM, Martin Thuresson wrote:
> This patch from Neil Vachharajani and Dehao Chen improves mcf by using
> minimum cost circulation instead of minimum cost flow to smooth profiles.
> It also introduces a parameter for controlling running time of
Counter overflow?
David
On Thu, Jun 2, 2011 at 11:12 AM, Martin Thuresson wrote:
> On Thu, Jun 2, 2011 at 11:05 AM, Xinliang David Li wrote:
>>
>> Smoothing works for sample FDO and profile data from multi-threaded
>> programs. You won't see any difference in SPE
Looks good to me, but you need an OK from a maintainer.
Thanks,
David
On Fri, Jun 3, 2011 at 7:17 AM, Alexandre Oliva wrote:
> A recent change introduced decl_uid in the “;; Function ” header in dump
> files. This breaks -fcompare-debug (and bootstrap-debug-lean), because
> decl uids aren't ke
Is this patch ok?
Thanks,
David
On Wed, Jun 1, 2011 at 10:24 AM, Xinliang David Li wrote:
> The attached is the split #1 patch that enhances -fenable/disable.
>
> Ok after testing?
>
> Thanks,
> David
>
> On Wed, Jun 1, 2011 at 9:16 AM, Xinliang David Li wrote:
>&g
801 - 900 of 1051 matches
Mail list logo
