I want propose a more general solution.
1) Generic Annotation Support for gcc IR -- it is used attach to
application/optimization specific annotation to gimple statements and
annotations can be passed around across passes. In gcc, I only see
HISTOGRAM annotation for value profiling, which is
Honza, what do you think of the patch? It actually fixed a regression.
Thanks,
David
On Wed, May 4, 2011 at 4:40 PM, Xinliang David Li davi...@google.com wrote:
Is this patch ok for trunk?
Allowing relative path in -fprofile-generate= is very useful when
running the program remotely
I can think of some more-or-less obvious high-level forms, one would
for example simply stick a new DISPATCH tree into gimple_call_fn
(similar to how we can have OBJ_TYPE_REF there), the DISPATCH
tree would be of variable length, first operand the selector function
and further operands
Is this patch ok for trunk?
Allowing relative path in -fprofile-generate= is very useful when
running the program remotely -- the profile data will be just dumped
in the dir relative to the working dir in the remote machine. Using
GCOV_PREFIX_STRIP can workaround the problem, but it is not always
for clone probably just hide the problem.
Thanks,
David
Honza
David
On Fri, Apr 29, 2011 at 4:38 PM, Xinliang David Li davi...@google.com
wrote:
During function cloning, the language field of the src func is not
copied. This can lead to null dereference when gcc calls into langhook
On Tue, May 3, 2011 at 3:00 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, May 3, 2011 at 1:07 AM, Xinliang David Li davi...@google.com wrote:
On Mon, May 2, 2011 at 2:33 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Mon, May 2, 2011 at 6:41 PM, Xinliang David Li
thanks. Will correct.
David
On Mon, May 2, 2011 at 2:03 AM, Rainer Orth r...@cebitec.uni-bielefeld.de
wrote:
David,
2011-05-01 David Li davi...@google.com
* testsuite/lib/profopt.exp (proc): Multiple source file support.
^
This is wrong, the
On Mon, May 2, 2011 at 2:11 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Fri, Apr 29, 2011 at 6:23 PM, Xinliang David Li davi...@google.com wrote:
Here is the background for this feature:
1) People relies on function multi-version to explore hw features and
squeeze performance
to google/main to make sure it is
available for our internal use at Google in order to materialize some
optimization opportunities. Let us continue this dicussion as I make
changes and submit this for review for trunk.
Thanks,
-Sri.
On Mon, May 2, 2011 at 9:41 AM, Xinliang David Li davi
Is this one ok?
David
On Fri, Apr 29, 2011 at 4:38 PM, Xinliang David Li davi...@google.com wrote:
During function cloning, the language field of the src func is not
copied. This can lead to null dereference when gcc calls into langhook
functions. Unfortunately, I lost track of the test case
On Mon, May 2, 2011 at 2:33 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Mon, May 2, 2011 at 6:41 PM, Xinliang David Li davi...@google.com wrote:
On Mon, May 2, 2011 at 2:11 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Fri, Apr 29, 2011 at 6:23 PM, Xinliang David Li
On Sun, May 1, 2011 at 7:16 AM, Jan Hubicka hubi...@ucw.cz wrote:
How about change tree_profile_ipa to tree-profile and
ipa-profile to profile-estimate -- basically drop the ipa in the
name. There are also many other passes using '_' though. Can tree
level pass_profile's name also be changed
I need this support for LIPO but it might be also useful for trunk.
The support is 'borrowed' from lib/lto.exp. I have tested with it and
it works fine. The only limitation is for any subdirectory with a
multi-source test case, all the other single source test case need
also to follow the same
On Sat, Apr 30, 2011 at 10:07 AM, Jan Hubicka hubi...@ucw.cz wrote:
On Sat, Apr 30, 2011 at 2:21 AM, Jan Hubicka hubi...@ucw.cz wrote:
On Fri, Apr 29, 2011 at 4:16 PM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
It seems that majority of testcases are independent of lipo. We could
probably
Here is the background for this feature:
1) People relies on function multi-version to explore hw features and
squeeze performance, but there is no standard ways of doing so, either
a) using indirect function calls with function pointers set at program
initialization; b) using manual dispatch at
} } */
+/* { dg-final { cleanup-tree-dump optimized } } */
Index: testsuite/ChangeLog
===
--- testsuite/ChangeLog (revision 173176)
+++ testsuite/ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2011-04-29 Xinliang David Li davi...@google.com
The old bug was that the second call to func got CSEed.
David
On Fri, Apr 29, 2011 at 4:08 PM, Xinliang David Li davi...@google.com wrote:
This test case was extracted from kernel source exposed in some older
version of gcc. Works fine in trunk, but need to add a test for it.
Ok for trunk
On Fri, Apr 29, 2011 at 4:16 PM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
It seems that majority of testcases are independent of lipo. We could probably
enjoy more of testing on mainline, so could you please take those working on
mainline and make mainline patch and let me know what of the tests
During function cloning, the language field of the src func is not
copied. This can lead to null dereference when gcc calls into langhook
functions. Unfortunately, I lost track of the test case.
Ok for trunk ?
Thanks,
David
2011-04-29 Xinliang David Li davi...@google.com
* tree
Introducing the parameters for FDO allows FDO specific tunings. In
general, these parameters are kludges lacking a better way of doing
it. In the long run, we are working on smarter mechanism to make
decisions based on hot program traces and locality regions as well as
information such as uArch
Sharad can provide some some performance data -- we have seen up to 2%
degradation to with tracer turned on for one of google's most
important program. Perhaps Sharad can collect some SPEC numbers.
I agree a better approach should be to fix the problem in tracer
instead of turning it off in
Tracer is not turned on by default for non-FDO case -- Sharad's change
simply turns it off by default for all cases.
David
On Thu, Apr 28, 2011 at 4:38 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Fri, Apr 29, 2011 at 1:34 AM, Xinliang David Li davi...@google.com wrote:
Sharad can
+ Honza
This patch may be a candidate for trunk as well. This feature not only
allows profile collection with much less overhead (for multi-thread
programs with hot regions, the slow down can be significant due to
cache ping-pong effect of counter update) without sacrificing too much
the
Ok for google/main.
David
On Thu, Apr 28, 2011 at 8:18 PM, Carrot Wei car...@google.com wrote:
Yes, after porting it to google/main.
Carrot
On Thu, Apr 28, 2011 at 10:26 PM, Diego Novillo dnovi...@google.com wrote:
Will you be proposing this patch for trunk as well?
Diego.
Honza, any more comments?
Thanks,
David
On Mon, Apr 25, 2011 at 9:35 AM, Xinliang David Li davi...@google.com wrote:
Is the patch ok?
Thanks,
David
On Fri, Apr 22, 2011 at 12:48 PM, Jan Hubicka hubi...@ucw.cz wrote:
Please review the new patch which only implements cfg checksum
On Wed, Apr 27, 2011 at 10:03 AM, Jan Hubicka hubi...@ucw.cz wrote:
- else if (entry-checksum != checksum)
+ else if (entry-lineno_checksum != lineno_checksum
+ || entry-cfg_checksum != cfg_checksum)
{
error (coverage mismatch for function
Hi please review the trivial patch below. It reduces race conditions
in value profiling. Another trivial change (to initialize
function_list struct) is also included.
Bootstrapped and regression tested on x86-64/linux.
Thanks,
David
2011-04-27 Xinliang David Li davi...@google.com
Ok -- false alarm ...
David
On Wed, Apr 27, 2011 at 5:30 PM, Nathan Froyd froy...@codesourcery.com wrote:
On Wed, Apr 27, 2011 at 04:23:42PM -0700, Xinliang David Li wrote:
This can happen when the module does not have function bodies.
- VEC_free (cgraph_node_ptr, heap, cgraph_node_map
Is the patch ok?
Thanks,
David
On Fri, Apr 22, 2011 at 12:48 PM, Jan Hubicka hubi...@ucw.cz wrote:
Please review the new patch which only implements cfg checksum.
The auto version generation was introduced in 2002 before FDO support
was added (so the old way never existed), so it might be
Sounds like a good idea, but does -Werror=xxx work for this ? I tried
cases with -Wstrict-aliasing, -Werror handling seems broken.
Thanks,
David
On Fri, Apr 22, 2011 at 1:52 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Thu, Apr 21, 2011 at 7:43 PM, Xinliang David Li davi
Looks like we won't get consensus (as Jeff mentioned) on the naming
etc. Shall I just commit this one?
Thanks,
David
On Fri, Apr 22, 2011 at 9:23 AM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
On Fri, Apr 22, 2011 at 3:52 AM, Richard Guenther
richard.guent...@gmail.com wrote:
, Xinliang David Li davi...@google.com wrote:
On Thu, Apr 21, 2011 at 1:43 PM, Jan Hubicka hubi...@ucw.cz wrote:
I don't really follow the logic here. buffer is allocated to be size of
block+4 and it is expected that gcov_write_words is not executed on size
greater than 4. Since gcov_write_string
Ping ..
David
On Wed, Apr 20, 2011 at 9:34 AM, Xinliang David Li davi...@google.com wrote:
This would work if there is a way to set Werror=coverage-mismatch
without having to explicitly set the option classification as
DK_ERROR. Does this mechanism exist?
Thanks,
David
On Tue, Apr 19
On Thu, Apr 21, 2011 at 10:21 AM, Jeff Law l...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/07/11 18:24, Xinliang David Li wrote:
Hi,
the following patch implements the option to fine control the emitted
warnings --
1) allow suppressing warnings for use of values
On Thu, Apr 21, 2011 at 1:36 PM, Jan Hubicka hubi...@ucw.cz wrote:
@@ -730,6 +726,8 @@ void cgraph_clone_inlined_nodes (struct
void compute_inline_parameters (struct cgraph_node *);
cgraph_inline_failed_t cgraph_edge_inlinable_p (struct cgraph_edge *);
+void cgraph_init_node_map (void);
On Thu, Apr 21, 2011 at 1:43 PM, Jan Hubicka hubi...@ucw.cz wrote:
I don't really follow the logic here. buffer is allocated to be size of
block+4 and it is expected that gcov_write_words is not executed on size
greater than 4. Since gcov_write_string now seems to be expected to handle
On Thu, Apr 21, 2011 at 12:54 PM, Joseph S. Myers
jos...@codesourcery.com wrote:
On Tue, 19 Apr 2011, Xinliang David Li wrote:
2011-04-18 Neil Vachharajani nvach...@gmail.com
* flags.c: New flag variable.
* opts.c (common_handle_options): Set flag_werror_set.
* opts-global.c
Please review the new patch.
Thanks,
David
On Thu, Apr 21, 2011 at 3:59 PM, Joseph S. Myers
jos...@codesourcery.com wrote:
On Thu, 21 Apr 2011, Xinliang David Li wrote:
On Thu, Apr 21, 2011 at 12:54 PM, Joseph S. Myers
jos...@codesourcery.com wrote:
On Tue, 19 Apr 2011, Xinliang David Li
AM, Xinliang David Li davi...@google.com wrote:
-Wcoverage-mismatch is enabled by default, and the warning is promoted
to error by default. However in the current implementation -Wno-error
can not demote the error back to warning. The patch was ported from
one contributed by Neil.
OK
Please review the latest patch. SPEC2k FDO testing pass.
Thanks,
David
On Wed, Apr 20, 2011 at 11:22 AM, Xinliang David Li davi...@google.com wrote:
Here is the revised patch. Basic FDO testing went fine. I still saw
the ipa-inline assertion in SPEC FDO. Will run it when the regression
On Tue, Apr 19, 2011 at 3:20 PM, Jan Hubicka hubi...@ucw.cz wrote:
I can not review tree.c changes. I would probably suggest making crc_byte
inline.
Diego, can you review this change? This is just a simple refactoring.
+#if IN_LIBGCOV
+
+/* These functions are guarded by #if to avoid
-Wcoverage-mismatch is enabled by default, and the warning is promoted
to error by default. However in the current implementation -Wno-error
can not demote the error back to warning. The patch was ported from
one contributed by Neil.
OK for trunk after regression testing?
2011-04-18 Neil
The attached is the revised patch with a warning suggested for cases
when CFG matches, but source locations change.
Ok for trunk?
thanks,
David
On Sun, Apr 17, 2011 at 8:36 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi, in current FDO implementation, the source file version used in
? (SPEC FDO testing is currently blocked by some regressions).
Thanks,
David
2011-04-19 Xinliang David Li davi...@google.com
* cgraph.h: New function declaration.
* cgraph.c (cgraph_remove_node): Remove from pid map.
* value-prof.c (find_func_by_pid): Handle
On Tue, Apr 19, 2011 at 2:38 PM, Jan Hubicka hubi...@ucw.cz wrote:
Hi, Insane value profile data may contain indirect call targets with
wrong (corrupted) pids. r172276 solves the problem when the pid
refers to a bogus target that is still 'alive'. This patch addresses
the issue when the bogus
So between hashtab and VEC, which one do you prefer? Either one is fine with me.
Thanks,
David
On Tue, Apr 19, 2011 at 3:39 PM, Jan Hubicka hubi...@ucw.cz wrote:
Why is VEC any better in terms of density ? Are you suggesting using a
hash table?
It is not any better, but we usually use VEC
On Tue, Apr 19, 2011 at 4:30 PM, Jan Hubicka hubi...@ucw.cz wrote:
On Tue, Apr 19, 2011 at 3:57 PM, Jan Hubicka hubi...@ucw.cz wrote:
So between hashtab and VEC, which one do you prefer? Either one is fine
with me.
I would go with VEC. While the array will have holes, there are not many
On Tue, Apr 19, 2011 at 4:49 PM, Jan Hubicka hubi...@ucw.cz wrote:
Actually, among all the choices, funcdef_no is probably the most dense
one -- it is for function decl with definition only. In LIPO, the
Yes, funddef_no is densiest, but we don't really need great density here
(in many other
On Sun, Apr 17, 2011 at 8:29 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi please review the attached patch.
Ok when bootstrap and test finish?
Thanks,
David
2011-04-07 Xinliang David Li davi...@google.com
* ipa-cp.c (ipcp_update_profiling): Correct
negative scale factor due
On Sun, Apr 17, 2011 at 8:36 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi, in current FDO implementation, the source file version used in
profile-generate needs to strictly match the version used in
profile-use -- simple formating changes will invalidate the profile
data (use of it will lead to
Adding assertion sounds good to me -- the only problem is that problem
like this hard to be triggered during testing, thus making assertion
less useful as it can be. Is it better to add the assertion with
checking is enabled while still keeping the correction code?
Thanks,
David
On Sun, Apr 17,
Resent in plain text mode ..
David
On Fri, Apr 15, 2011 at 9:28 AM, Xinliang David Li davi...@google.com wrote:
Honza, do you have a chance to take a look at it?
Thanks,
David
On Wed, Apr 13, 2011 at 3:25 PM, Xinliang David Li davi...@google.com wrote:
Hi, in current FDO implementation
This is a trivial patch to deal with bad profile data (from
multi-threaded programs) that leads to divide by zero error.
Ok for trunk?
Thanks,
David
2011-04-15 Xinliang David Li davi...@google.com
* ipa-inline.c (cgraph_decide_recursive_inlining): Fix
div by zero error
There is no way to get a test case that can produce the problem in a
deterministic way. There is really not much for Honza to review
though :)
David
On Fri, Apr 15, 2011 at 12:52 PM, Diego Novillo dnovi...@google.com wrote:
On Fri, Apr 15, 2011 at 15:20, Xinliang David Li davi...@google.com
this.
1) function checksum is split into two parts: lineno checksum and cfg checksum
2) function assembler name is used in profile hashing.
Bootstrapped and regression tested on x86_64/linux.
Ok for trunk?
Thanks,
David
2011-04-13 Xinliang David Li davi...@google.com
* tree.c
This was contributed by:
2011-04-13 Neil Vachharajani nvach...@gmail.com
On Wed, Apr 13, 2011 at 3:25 PM, Xinliang David Li davi...@google.com wrote:
Hi, in current FDO implementation, the source file version used in
profile-generate needs to strictly match the version used in
profile-use
Is this patch OK?
Thanks,
David
On Sat, Apr 9, 2011 at 9:34 AM, Xinliang David Li davi...@google.com wrote:
SPEC06 build with FDO is ok with the patch -- no abnormality was found.
David
On Fri, Apr 8, 2011 at 2:42 PM, Xinliang David Li davi...@google.com wrote:
Please review this patch
SPEC06 build with FDO is ok with the patch -- no abnormality was found.
David
On Fri, Apr 8, 2011 at 2:42 PM, Xinliang David Li davi...@google.com wrote:
Please review this patch. Regression test is ok. I will do more
application testing to make sure the check is not too strict
(filtering out
David Li davi...@google.com
* value-profile.c (function_decl_num_args): New function.
(check_ic_target): New function.
(gimple_ic_transform): Sanity check indirect call target.
check_ic.p
Description: Binary data
Ping?
On Sun, Apr 3, 2011 at 5:54 PM, Xinliang David Li davi...@google.com wrote:
For an assembly dump, it is very useful to examine the control flow
graph with frequency and profile count information. This requires
dumping the .s file with more control flow annotations. This patch
does just
On Fri, Apr 8, 2011 at 5:04 AM, Diego Novillo dnovi...@google.com wrote:
On 04/03/2011 08:54 PM, Xinliang David Li wrote:
+
+ fprintf (file, # BLOCK %d, bb-index);
+ if (bb-frequency)
+ fprintf (file, freq:%d, bb-frequency);
+ if (bb-count)
+ fprintf (file
Please review this patch. Regression test is ok. I will do more
application testing to make sure the check is not too strict
(filtering out legal ic targets).
Thanks,
David
2011-04-07 Xinliang David Li davi...@google.com
* value-profile.c (function_decl_num_args): New function
Hi, this patch fixes the test failure. OK after bootstrap and regression test?
Thanks,
David
2011-04-08 Xinliang David Li davi...@google.com
PR tree-optimization/PR48484
* tree-ssa-uninit.c (convert_control_dep_chain_into_preds): Set
has_valid_pred lazily
2011-04-08
:
-Wno-error=maybe-uninitialized
This is useful for users who only care about definite uninitialized
variable warnings.
Ok for trunk?
thanks,
David
2011-04-07 Xinliang David Li davi...@google.com
* tree-ssa-uninit.c (warn_uninitialized_phi): Pass
warning code.
* c
-tree-xxx-blocks so the same
post-processing tools can be shared to generate the .dot file. To see
bb layout, the BB sequence number is also dumped.
Bootstrapped on x86-64/linux. Regression test is on going.
Ok for checkin?
Thanks,
David
2011-04-03 Xinliang David Li davi...@google.com
On Fri, Mar 11, 2011 at 11:50 AM, Jeff Law l...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/09/11 09:24, Xinliang David Li wrote:
On Wed, Mar 9, 2011 at 6:03 AM, Jeff Law l...@redhat.com wrote:
On 03/09/11 02:45, Richard Guenther wrote:
On Tue, Mar 8, 2011 at 11:04
:55, Diego Novillo wrote:
On 03/08/2011 12:54 PM, Xinliang David Li wrote:
Please review the attached patch, it does some simplification of the
complicated logical or expressions (x1 or x2 or x3 ...) constructed
from control flow analysis into simpler form.
Bootstraps and works on s390x for both
On Wed, Mar 9, 2011 at 6:03 AM, Jeff Law l...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/09/11 02:45, Richard Guenther wrote:
On Tue, Mar 8, 2011 at 11:04 PM, Jeff Law l...@redhat.com wrote:
True. I've been repeatedly thinking of building some on-the-side CFG
On Wed, Mar 9, 2011 at 8:29 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Mar 9, 2011 at 5:24 PM, Xinliang David Li davi...@google.com wrote:
On Wed, Mar 9, 2011 at 6:03 AM, Jeff Law l...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/09/11 02:45
at 9:54 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Mar 9, 2011 at 6:34 PM, Xinliang David Li davi...@google.com wrote:
On Wed, Mar 9, 2011 at 8:29 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Mar 9, 2011 at 5:24 PM, Xinliang David Li davi...@google.com
wrote
901 - 970 of 970 matches
Mail list logo
