On Mon, Jun 4, 2012 at 12:49 AM, Nathan Sidwell wrote:
> On 06/03/12 21:40, Xinliang David Li wrote:
>
>>> Can you explain this more -- what exactly are trying to do? Are you
>>> trying
>>> to rebuild multiple times with the same coverage data,
>>
>&
On Sun, Jun 3, 2012 at 10:24 AM, Nathan Sidwell wrote:
> On 06/03/12 17:16, Xinliang David Li wrote:
>
>> Basically it makes it very difficult to rebuild the file with the
>> profile data --- which makes problem triaging impossible. What is
>
>
> Can you explain th
On Sun, Jun 3, 2012 at 6:10 AM, Nathan Sidwell wrote:
> On 06/03/12 05:51, Xinliang David Li wrote:
>>
>> On Fri, Dec 30, 2011 at 10:25 AM, Nathan Sidwell wrote:
>>>
>>> I've committed this patch to fix and improve coverage reporting:
>>>
>>
2. change to use deferred option.
>
> Thanks,
> Dehao
>
> On Sun, Jun 3, 2012 at 12:40 PM, Xinliang David Li wrote:
>> On Sat, Jun 2, 2012 at 11:11 AM, Jan Hubicka wrote:
>>>> Actually Dehao also plans to teach the static predictor to understand
>>>> s
On Fri, Dec 30, 2011 at 10:25 AM, Nathan Sidwell wrote:
> I've committed this patch to fix and improve coverage reporting:
>
> 1) the time stamp local_tick will be -1 if the user overrides the random
> seed. In such cases the gcov data file should be deleted, just as it would
> if the time cannot
On Sat, Jun 2, 2012 at 11:11 AM, Jan Hubicka wrote:
>> Actually Dehao also plans to teach the static predictor to understand
>> standard library functions more (e.g IO functions) and add more naming
>
> How this differ from annotating the library?
I find them more suitable to be compiler heuristi
Based on Honza's feedback, I think it is bettre to add command line
interface such as this:
-ffunction-attribute-list=:
or
-ffunction-attribute-filelist=:
e.g,
-ffunction-attribute-list=code:foo1,foo2,bar_*,blah
It probably needs to be processed as deferred option to allow other
option to be tr
On Sat, Jun 2, 2012 at 3:06 AM, Jan Hubicka wrote:
>> On Sat, Jun 2, 2012 at 2:36 AM, Jan Hubicka wrote:
>> >> Hi,
>> >>
>> >> This patch adds 4 flags to enable user to type in a list of name
>> >> patterns. Compiler will match the function name with the given
>> >> patterns, and add "hot", "cold
On Sat, Jun 2, 2012 at 2:36 AM, Jan Hubicka wrote:
>> Hi,
>>
>> This patch adds 4 flags to enable user to type in a list of name
>> patterns. Compiler will match the function name with the given
>> patterns, and add "hot", "cold", "likely_hot", "likely_cold"
>> attributes to function declaration.
ok.
thanks,
David
On Fri, Jun 1, 2012 at 2:26 PM, Teresa Johnson wrote:
> Renamed to __gcov_dummy_ref1 and __gcov_dummy_ref2. I'd prefer that
> approach for now to keep the differences with trunk to a minimum.
>
> Thanks,
> Teresa
>
> On Fri, Jun 1, 2012 at 2:18 PM, wrote:
>> Ok with better n
On Fri, Jun 1, 2012 at 1:26 AM, Dehao Chen wrote:
> Hi,
>
> This patch adds 4 flags to enable user to type in a list of name
> patterns. Compiler will match the function name with the given
> patterns, and add "hot", "cold", "likely_hot", "likely_cold"
> attributes to function declaration. The sta
Ok.
David
On Thu, May 24, 2012 at 11:38 AM, Rong Xu wrote:
> Hi,
>
> This is for google branches only.
>
> It changes the format of the temp function name so that they
> can be demangled.
>
> Tested with regression tests.
>
> Google ref b/5733865.
>
> Thanks,
>
> 2012-05-24 Rong Xu
>
>
ok for google-4_7 branch. This should also be pushed to trunk.
Thanks,
David
On Wed, May 16, 2012 at 6:56 PM, Sriraman Tallam wrote:
> Patch too large to be attached, rejected by gcc-patches. Please see:
>
> http://codereview.appspot.com/download/issue6195099_1.diff
>
> Thanks,
> -Sri.
>
> On W
Looks good.
thanks,
David
On Mon, May 14, 2012 at 7:18 PM, Teresa Johnson wrote:
> Two cleanup items for the sampling instrumentation interfaces. First,
> rename variables from *rate* to *period*, since what is being specified
> is a sampling period (time between recorded samples) not a rate.
>
On Sat, May 12, 2012 at 9:26 AM, Gabriel Dos Reis
wrote:
> On Sat, May 12, 2012 at 11:05 AM, Xinliang David Li
> wrote:
>
>> The downside is that the dump file format will look different from the
>> stderr output which is less than ideal.
>
> BTW, why do people wan
Sounds good.
On Sat, May 12, 2012 at 3:31 AM, Richard Guenther
wrote:
> On Fri, May 11, 2012 at 8:11 PM, Xinliang David Li wrote:
>> To be more specific, does the following match what your envisioned?
>>
>> 1) when multiple streams are specified for dumping, the information
-fopt-info=N, and take -ftree-vectorizer-verbose as the
first guinea pig to use the new dumping interfaces.
After the infrastructure is ready, gradually deprecate the use of the
original dumper interfaces.
what do you think?
thanks,
David
On Fri, May 11, 2012 at 9:06 AM, Xinliang David Li wrote
On Fri, May 11, 2012 at 1:49 AM, Richard Guenther
wrote:
> On Thu, May 10, 2012 at 6:28 PM, Xinliang David Li wrote:
>> I like your suggestion and support the end goal you have. I don't
>> like the -fopt-info behavior to interfere with regular -fdump-xxx
>> option
ge?
After this one is checked in, the new dump interfaces will be worked
on (and to allow multiple streams). Most of the remaining changes will
be massive text replacement.
thanks,
David
On Thu, May 10, 2012 at 1:18 AM, Richard Guenther
wrote:
> On Thu, May 10, 2012 at 2:31 AM, Xinliang Da
Bummer. I was thinking to reserve '=' for selective dumping:
-fdump-tree-pre=
I guess this can be achieved via @
-fdump-tree-pre@
-fdump-tree-pre=@
Another issue -- I don't think the current precedence rule is correct.
Consider that -fopt-info=2 will be mapped to
-fdump-tree-all-transform-
On Wed, May 9, 2012 at 11:21 AM, Richard Guenther
wrote:
> On Wed, May 9, 2012 at 6:32 PM, Xinliang David Li wrote:
>> On Wed, May 9, 2012 at 1:12 AM, Richard Guenther
>> wrote:
>>> On Tue, May 8, 2012 at 6:18 PM, Xinliang David Li
>>> wrote:
>>
On Wed, May 9, 2012 at 1:12 AM, Richard Guenther
wrote:
> On Tue, May 8, 2012 at 6:18 PM, Xinliang David Li wrote:
>> To be clear, this flag is for malloc implementation (such as tcmalloc)
>> with side effect unknown to the compiler. Using -fno-builtin-xxx is
>> too conserva
Ok.
David
On Tue, May 8, 2012 at 9:53 AM, Rong Xu wrote:
> Hi,
>
> This patch is for google-4_6 branch only.
>
> It fixes a profile mismatch in streaming LIPO and recovers the performance
> loss
> due to this.
>
> Tested with google internal benchmarks.
>
> Thanks,
>
> 2012-05-08 Rong Xu
>
To be clear, this flag is for malloc implementation (such as tcmalloc)
with side effect unknown to the compiler. Using -fno-builtin-xxx is
too conservative for that purpose.
David
On Tue, May 8, 2012 at 7:43 AM, Dehao Chen wrote:
> Hello,
>
> This patch adds a flag to guard the optimization that
+Honza and Nathan.
David
On Thu, May 3, 2012 at 10:52 AM, Teresa Johnson wrote:
> This patch adds functionality to libgcov to enable user applications to
> collect profile data only in regions of interest. This is useful, for
> example, to collect profile data from a long-running server only
> d
ok. Is the change in google-47 branch?
Please also submit this to trunk (there was also a previous one pending).
thanks,
David
On Thu, May 3, 2012 at 4:44 AM, Dehao Chen wrote:
> Hi,
>
> This patch was reverted because of performance degradation. However, it
> turns out to be an innocent perfo
ok.
David
On Tue, May 1, 2012 at 3:47 PM, wrote:
> Reviewers: xur, davidxl,
>
> Message:
> Please take a look at this.
>
> Description:
> This fixes an issue with profile collection when multiple threads call
> fork() around the same time.
>
> 2012-03-12 Richard Guenther
>
> * gthr.h
ok. Needs to be in google47 and google/main too.
David
On Tue, May 1, 2012 at 3:26 PM, Rong Xu wrote:
> Hi,
>
> This patch is for google-4_6 branch only.
>
> It fixes a undefined type-info reference in LIPO compilation.
>
> Tested with bootstrap, SPEC and internal benchmarks.
>
> Thanks,
>
> 20
On Fri, Apr 27, 2012 at 12:07 AM, Igor Zamyatin wrote:
> Are you sure that tree-level unrollers are turned on at O2? My
> impression was that they work only at O3 or with f[unroll,peel]-loops
> flags.
yes they are on but only have effect on tiny loops with very small
trip count. With O3 or with -
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.
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
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
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
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 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,
>>>
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
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 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) ):
&
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
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
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
>
>
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
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/
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
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
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
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
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
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.
>
>
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
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
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
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
On Wed, Mar 7, 2012 at 5:51 AM, Richard Guenther
wrote:
> On Wed, Mar 7, 2012 at 1:49 AM, Sriraman Tallam wrote:
>> Patch for CPU detection at run-time.
>> ===
>>
>> Patch for CPU detection at run-time, to be used in dispatching of
>> multi-versioned functions. P
ok.
David
On Thu, Mar 8, 2012 at 10:04 AM, Rong Xu wrote:
> Hi,
>
> This patch is for google-4_6 branch only.
>
> It fixes a bug in r184378 which makes some capping escape (like
> stale max_bb_count in cgraph node).
>
> Tested with the internal benchmark that exposes this issue.
> Tested with gc
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
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
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.
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 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
. 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?
>>
>
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
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
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.
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,
>
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)
>> + {
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
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
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
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
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
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
>>
>
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
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)
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:
>>
>&
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
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,
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.
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
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
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.
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 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 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 -- 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
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
.
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 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/
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
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
> +/* 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
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
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
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
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
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
>> ===
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
;
>
> +/* 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_
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
>> >>
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
701 - 800 of 1034 matches
Mail list logo
