Re: [GOOGLE] Remove overly-aggressive LIPO assert

Ping. Thanks, Teresa On Wed, Dec 2, 2015 at 12:46 PM, Teresa Johnson <tejohn...@google.com> wrote: > Remove an assert that was overly-strict and already partially redundant > with an immediately prior assert. In this case we had a hidden visibility > function clone that was created

[GOOGLE] Remove overly-aggressive LIPO assert

regression tests. Ok for Google branch? 2015-12-02 Teresa Johnson <tejohn...@google.com> Google ref b/25925223. * l-ipo.c (cgraph_lipo_get_resolved_node_1): Remove overly-strict assert. Index: l-ipo.c === --- l-ipo.c (re

Re: [PATCH]Add -fprofile-use option for check_effective_target_freorder.

og: > > 2015-10-26 Renlin Li <renlin...@arm.com> > > * lib/target-supports.exp (check_effective_target_freorder): Add > -fprofile-use flag. -- Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413

[GOOGLE] Reduce max-vartrack-size

Reduce the maximum variable tracking size by 20% to avoid extreme compilation times. Ok for google-4_9? 2015-10-13 Teresa Johnson <tejohn...@google.com> Google ref b/24569916 * params.def (PARAM_MAX_VARTRACK_SIZE): Reduce default to 40M. Index: para

Re: [PATCH] Disable -fno-reorder-blocks-and-partition if no -fprofile-use to avoid unnecessary overhead

ntry that Bernd pointed out. Thanks, Teresa > > Honza >> heuristics are used to distinguish cold bbs in >> probably_never_executed_bb_p, I don't think it makes sense to do >> anything finer grained that just disabling the option. >> >> Teresa >> >>

[GOOGLE] Disable -fno-reorder-blocks-and-partition if no -fprofile-use to avoid unnecessary overhead

-25 Teresa Johnson <tejohn...@google.com> Google ref b/24265250 * opts.c (finish_options): Unset -freorder-blocks-and-partition if not using profile. (set_profile_use_options): Unset -freorder-blocks-and-partition if input profile not found and it

Re: [PATCH] Disable -fno-reorder-blocks-and-partition if no -fprofile-use to avoid unnecessary overhead

Woops, we crossed wires. I just committed this patch. Would you like me to revert it? Teresa On Fri, Sep 25, 2015 at 9:57 AM, Andi Kleen <a...@firstfloor.org> wrote: > Teresa Johnson <tejohn...@google.com> writes: > >> This patch unsets -freorder-blocks-and-part

Re: [PATCH] Disable -fno-reorder-blocks-and-partition if no -fprofile-use to avoid unnecessary overhead

On Fri, Sep 25, 2015 at 6:58 AM, Bernd Schmidt <bschm...@redhat.com> wrote: > On 09/24/2015 07:16 PM, Teresa Johnson wrote: >> >> This patch unsets -freorder-blocks-and-partition when -fprofile-use >> is not specified. Function splitting was not actually bein

[PATCH] Disable -fno-reorder-blocks-and-partition if no -fprofile-use to avoid unnecessary overhead

, however, causes the assembly code generator to create (empty) cold sections and labels, leading to unnecessary size overhead. Bootstrapped and tested on x86-64-unknown-linux-gnu. Ok for trunk? Thanks, Teresa 2015-09-24 Teresa Johnson <tejohn...@google.com> * opts.c (finish_options):

[GOOGLE] Reset lambda scope information when popping module for LIPO

now (and has for awhile) encompasses more than just deferred function clearing. Passes regression tests. Ok for google 4_9? 2015-08-14 Teresa Johnson tejohn...@google.com Google ref b/23176787. * cp/cp-lang.c: Rename clear_deferred_fns to reset_parsing_state. * cp/cp

Re: [GOOGLE] Only save command-line options for LIPO

Resending in plain text mode. On Wed, Jul 8, 2015 at 11:34 AM, Teresa Johnson tejohn...@google.com wrote: This patch avoids saving optimization pragma or function level attributes in the list of command line options saved in the LIPO module info structure. Passes regression and internal

Re: [GOOGLE] Fixes for TLS wrapper and init functions in LIPO mode

On Thu, Mar 19, 2015 at 10:38 PM, Xinliang David Li davi...@google.com wrote: On Thu, Mar 19, 2015 at 9:57 PM, Teresa Johnson tejohn...@google.com wrote: On Thu, Mar 19, 2015 at 8:00 PM, Xinliang David Li davi...@google.com wrote: ok -- then there is an over assertion in get_local_tls_init_fn

Re: [GOOGLE] Fixes for TLS wrapper and init functions in LIPO mode

the tests to validate rather than print the expected output. Ok for google branches? 2015-03-20 Teresa Johnson tejohn...@google.com gcc/ Google ref b/19618364. * cp/decl2.c (get_local_tls_init_fn): Mark static, record new global at module scope

Re: [GOOGLE] Fixes for TLS wrapper and init functions in LIPO mode

New patch below. Passes regression tests plus internal application build. 2015-03-19 Teresa Johnson tejohn...@google.com gcc/ Google ref b/19618364. * cp/decl2.c (get_local_tls_init_fn): Assert on aux module. (get_tls_init_fn): Promote non-public init functions

Re: [GOOGLE] Fixes for TLS wrapper and init functions in LIPO mode

module). Teresa David On Thu, Mar 19, 2015 at 4:11 PM, Teresa Johnson tejohn...@google.com wrote: New patch below. Passes regression tests plus internal application build. 2015-03-19 Teresa Johnson tejohn...@google.com gcc/ Google ref b/19618364. * cp/decl2.c

Re: [GOOGLE] Fixes for TLS wrapper and init functions in LIPO mode

they are not marked static, so that would also need to be done to get them promoted. Teresa David On Thu, Mar 19, 2015 at 5:51 PM, Teresa Johnson tejohn...@google.com wrote: On Thu, Mar 19, 2015 at 4:45 PM, Xinliang David Li davi...@google.com wrote: does generate_tls_wrapper also need

Re: [GOOGLE] Fixes for TLS wrapper and init functions in LIPO mode

the original test case (forgot to include in first patch) and the new one with the fixed patch. Teresa David On Wed, Mar 18, 2015 at 9:18 PM, Teresa Johnson tejohn...@google.com wrote: Ensure TLS variable wrapper and init functions are recorded at the module scope upon creation so

[GOOGLE] Refine LIPO aux function removal

? Thanks, Teresa 2015-01-02 Teresa Johnson tejohn...@google.com Google ref b/18882262. * cgraph.c (cgraph_can_remove_if_no_direct_calls_and_refs_p): Keep aux functions until after LIPO linking. Index: cgraph.c

Re: [GOOGLE] Make LIPO aux function removal consistent

Ping. Teresa On Fri, Dec 19, 2014 at 5:40 PM, Teresa Johnson tejohn...@google.com wrote: Passes regression tests, ok for google 4_9? Thanks, Teresa 2014-12-19 Teresa Johnson tejohn...@google.com Google ref b/18800499 * cgraph.c

[GOOGLE] Make LIPO aux function removal consistent

Passes regression tests, ok for google 4_9? Thanks, Teresa 2014-12-19 Teresa Johnson tejohn...@google.com Google ref b/18800499 * cgraph.c (cgraph_can_remove_if_no_direct_calls_and_refs_p): Make consistent with mark_functions_for_output for LIPO aux functions. Index

Re: [PATCH] Fix PR/63841: empty constructor doesn't zero-initialize

, 2014 at 9:40 PM, Andrew Pinski pins...@gmail.com wrote: On Wed, Nov 12, 2014 at 9:38 PM, Teresa Johnson tejohn...@google.com wrote: On Wed, Nov 12, 2014 at 9:30 PM, Andrew Pinski pins...@gmail.com wrote: On Wed, Nov 12, 2014 at 9:25 PM, Teresa Johnson tejohn...@google.com wrote: Added testcase

Re: [PATCH] Fix PR/63841: empty constructor doesn't zero-initialize

On Thu, Nov 13, 2014 at 6:32 AM, Richard Biener richard.guent...@gmail.com wrote: On Thu, Nov 13, 2014 at 3:32 PM, Richard Biener richard.guent...@gmail.com wrote: On Thu, Nov 13, 2014 at 3:20 PM, Teresa Johnson tejohn...@google.com wrote: Here is the new patch. Bootstrapped and tested

Re: [PATCH] Fix PR/63841: empty constructor doesn't zero-initialize

On Thu, Nov 13, 2014 at 6:36 AM, Jakub Jelinek ja...@redhat.com wrote: On Thu, Nov 13, 2014 at 06:20:16AM -0800, Teresa Johnson wrote: Here is the new patch. Bootstrapped and tested on x86_64-unknown-linux-gnu. OK for trunk? Thanks, Teresa 2014-11-13tejohn...@google.com gcc

Re: [PATCH] Fix PR/63841: empty constructor doesn't zero-initialize

On Thu, Nov 13, 2014 at 7:12 AM, Jakub Jelinek ja...@redhat.com wrote: On Thu, Nov 13, 2014 at 06:46:23AM -0800, Teresa Johnson wrote: --- tree.c (revision 217190) +++ tree.c (working copy) @@ -10330,6 +10330,8 @@ initializer_zerop (const_tree init) { unsigned

Re: [PATCH] Fix PR/63841: empty constructor doesn't zero-initialize

On Thu, Nov 13, 2014 at 7:39 AM, Teresa Johnson tejohn...@google.com wrote: On Thu, Nov 13, 2014 at 7:12 AM, Jakub Jelinek ja...@redhat.com wrote: And for release branches I'd really prefer tree-ssa-strlen.c change. Ok, I started testing the initializer_zerop change on the 4_9 branch

Re: [PATCH] Fix PR/63841: empty constructor doesn't zero-initialize

On Thu, Nov 13, 2014 at 12:55 PM, Jakub Jelinek ja...@redhat.com wrote: On Thu, Nov 13, 2014 at 12:51:05PM -0800, Teresa Johnson wrote: On Thu, Nov 13, 2014 at 7:39 AM, Teresa Johnson tejohn...@google.com wrote: On Thu, Nov 13, 2014 at 7:12 AM, Jakub Jelinek ja...@redhat.com wrote

Re: [PATCH] Fix PR/63841: empty constructor doesn't zero-initialize

On Thu, Nov 13, 2014 at 1:45 PM, Jakub Jelinek ja...@redhat.com wrote: On Thu, Nov 13, 2014 at 01:33:07PM -0800, Teresa Johnson wrote: Supposedly the printfs should have been removed and the #include cstdio isn't needed then either. No need to clutter the test output and log files

[PATCH] Fix PR/63841: empty constructor doesn't zero-initialize

(elt)) return false; -- Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413

Re: [PATCH] Fix PR/63841: empty constructor doesn't zero-initialize

, Nov 12, 2014 at 2:13 PM, Teresa Johnson tejohn...@google.com wrote: This patch fixes an issue where tree-strlen was incorrectly removing a store of 0 into a string because it thought a prior CLOBBER (which is an empty constructor with no elements) was zero-initializing the string. Bootstrapped

Re: [PATCH] Fix PR/63841: empty constructor doesn't zero-initialize

On Wed, Nov 12, 2014 at 9:30 PM, Andrew Pinski pins...@gmail.com wrote: On Wed, Nov 12, 2014 at 9:25 PM, Teresa Johnson tejohn...@google.com wrote: Added testcase. Here is the new patch: 2014-11-12tejohn...@google.com gcc: PR tree-optimization/63841 * tree.c

Re: [PING][PATCH]Partially fix PR61529, bound basic block frequency

Hi Renlin, Looks like Jeff already approved it: Can you add a testcase please? With a testcase, this patch is OK for the trunk. Teresa On Mon, Nov 10, 2014 at 8:59 AM, Renlin Li renlin...@arm.com wrote: On 06/11/14 18:07, Renlin Li wrote: On 06/11/14 17:59, Teresa Johnson wrote: Thanks

Re: [PATCH]Partially fix PR61529, bound basic block frequency

wrote: On 29/10/14 12:42, Teresa Johnson wrote: Hi Renlin, Are the incoming edge counts or probabilities insane in this case? I guess the patch is ok if we need to do this to handle those incoming insanitiles. But I can't approve patches myself. Not really, it's just a little bigger than

Re: [PATCH]Partially fix PR61529, bound basic block frequency

PR middle-end/61529 * tree-ssa-threadupdate.c (compute_path_counts): Bound path_in_freq. This is needed due to insane incoming frequencies. gcc/testsuite/ChangeLog: 2014-11-06 Renlin Li renlin...@arm.com PR middle-end/61529 * gcc.dg/pr61529.c: New. -- Teresa Johnson

Re: [PATCH]Partially fix PR61529, bound basic block frequency

middle-end/61529 * tree-ssa-threadupdate.c (compute_path_counts): Bound path_in_freq. -- Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413

Re: [GOOGLE] Fix LIPO resolved node reference fixup

Here is the new patch that walks op looking for the reference to addr. Passes internal benchmarks and regression tests. Ok for google/4_9? Thanks, Teresa 2014-10-27 Teresa Johnson tejohn...@google.com Google ref b/18110567. * cgraphbuild.c (fixup_all_refs_1): New function

[GOOGLE] Fix LIPO resolved node reference fixup

This patch makes a fix to the reference fixups performed after LIPO node resolution, to better handle the case where we are updating the base address of a reference. Fixes google benchmark and passes regression tests. Ok for google/4_9? Thanks, Teresa 2014-10-24 Teresa Johnson tejohn

Re: [GOOGLE] Fix LIPO resolved node reference fixup

with the assert. Teresa David On Fri, Oct 24, 2014 at 10:21 AM, Teresa Johnson tejohn...@google.com wrote: This patch makes a fix to the reference fixups performed after LIPO node resolution, to better handle the case where we are updating the base address of a reference. Fixes google benchmark

[GOOGLE] Disable -fdevirtualize by default

Disabling devirtualization reduces code size, both for instrumentation (because many more virtual functions are kept longer and therefore instrumented) and for normal optimization. Patch attached. Passes internal testing and regression tests. Ok for google/4_9? Thanks, Teresa -- Teresa Johnson

[GOOGLE] Increase max-early-inliner-iterations to 2 for profile-gen and use

. Ok for google/4_9? 2014-10-18 Teresa Johnson tejohn...@google.com Google ref b/17934523 * opts.c (finish_options): Increase max-early-inliner-iterations to 2 for profile-gen and profile-use builds. Index: opts.c

Re: [GOOGLE] Increase max-early-inliner-iterations to 2 for profile-gen and use

. Ok for google/4_9? 2014-10-18 Teresa Johnson tejohn...@google.com Google ref b/17934523 * opts.c (finish_options): Increase max-early-inliner-iterations to 2 for profile-gen and profile-use builds. Index: opts.c

Re: [GOOGLE] Disable -fdevirtualize by default

the difference should not be big - perhaps I could make switch for that for mainline) and less accurate profiles when you get speculative devirtualization via topn. I would be very interested to see how much difference this makes. Honza -- Teresa Johnson | Software Engineer

[GOOGLE] Treat artificial from aux modules as non-external

, passes regression tests. Ok for google/4_9? Thanks, Teresa 2014-10-16 Teresa Johnson tejohn...@google.com Google ref b/17971995. * l-ipo.c (cgraph_is_aux_decl_external): Artificial functions may not be available in primary module. Index: l-ipo.c

[PATCH] Better tolerance of incoming profile insanities in jump threading

and tested on x86_64-unknown-linux-gnu. Ok for trunk? Thanks, Teresa 2014-10-14 Teresa Johnson tejohn...@google.com PR bootstrap/63432 * tree-ssa-threadupdate.c (recompute_probabilities): Better overflow checking. Index: tree-ssa-threadupdate.c

[Google] Put time profiling under param, disable by default

main Passes regression tests. Ok for google/4_9? 2014-10-12 Teresa Johnson tejohn...@google.com Google ref b/17945455. gcc/ * params.def (PARAM_PROFILE_VALUES_TIME): New parameter. * value-prof.c (gimple_find_values_to_profile): Use new param. gcc/testsuite

[GOOGLE] Handle missing BINFO for LIPO

. Passes regression tests. Ok for google branches? Teresa 2014-10-07 Teresa Johnson tejohn...@google.com Google ref b/16511102. * ipa-devirt.c (polymorphic_type_binfo_p): Handle missing BINFO. Index: ipa-devirt.c

[PATCH] Fix PR bootstrap/63432 in jump threading

. Bootstrapped and tested on x86_64-unknown-linux-gnu. Also did an LTO profiledbootstrap. Ok for trunk? Thanks, Teresa 2014-10-07 Teresa Johnson tejohn...@google.com PR bootstrap/63432. * tree-ssa-threadupdate.c (estimated_freqs_path): New function

[GOOGLE] Skip fake LIPO edges when replacing calls with local alias

Adds handling in this block of code (new in gcc/4_9 and therefore google/4_9) for LIPO fake edges for indirect calls, which don't have a call_stmt set and cannot be redirected. Passes regression tests, ok for google/4_9 branch? Teresa 2014-10-03 Teresa Johnson tejohn...@google.com

Re: [google gcc-4_9] fix undefined references in debug_info

). We need to output this label because it's a user label and debug_info has a reference to it. Tested with problematic file and regression test. Trunk may also have the same issue, but I need to work on a testcase. Thanks, -Rong -- Teresa Johnson | Software Engineer | tejohn

Re: [GOOGLE] Skip fake LIPO edges when replacing calls with local alias

Johnson tejohn...@google.com wrote: Adds handling in this block of code (new in gcc/4_9 and therefore google/4_9) for LIPO fake edges for indirect calls, which don't have a call_stmt set and cannot be redirected. Passes regression tests, ok for google/4_9 branch? Teresa 2014-10-03 Teresa

Re: [PATCH] Redesign jump threading profile updates

On Wed, Oct 1, 2014 at 10:02 PM, Teresa Johnson tejohn...@google.com wrote: On Wed, Oct 1, 2014 at 3:46 PM, Steve Ellcey sell...@mips.com wrote: On Wed, 2014-10-01 at 13:04 -0700, Teresa Johnson wrote: 2014-10-01 Teresa Johnson tejohn...@google.com * tree-ssa-threadupdate.c

Re: [PATCH] Redesign jump threading profile updates

On Thu, Oct 2, 2014 at 8:45 AM, Steve Ellcey sell...@mips.com wrote: On Wed, 2014-10-01 at 22:02 -0700, Teresa Johnson wrote: Will take a look. In case I can't reproduce it with the aarch64 cross-compiler or x86_64, can you give me the preprocessed source? And also the instructions for how

Re: [PATCH] Fix PR63422 to handle profile insanities

On Wed, Oct 1, 2014 at 10:03 AM, Xinliang David Li davi...@google.com wrote: Probably need to file a bug to track the copyrename2 problem. I have filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63443 to track this. David On Wed, Oct 1, 2014 at 9:59 AM, Teresa Johnson tejohn...@google.com

Re: [PATCH] Redesign jump threading profile updates

Sorry, yes, will try to reproduce. Teresa On Wed, Oct 1, 2014 at 12:03 AM, Christophe Lyon christophe.l...@linaro.org wrote: On 30 September 2014 20:20, Teresa Johnson tejohn...@google.com wrote: On Mon, Sep 29, 2014 at 9:33 PM, Jeff Law l...@redhat.com wrote: On 09/29/14 08:19, Teresa Johnson

Re: [PATCH] Redesign jump threading profile updates

On Wed, Oct 1, 2014 at 6:20 AM, Teresa Johnson tejohn...@google.com wrote: Sorry, yes, will try to reproduce. Teresa On Wed, Oct 1, 2014 at 12:03 AM, Christophe Lyon christophe.l...@linaro.org wrote: On 30 September 2014 20:20, Teresa Johnson tejohn...@google.com wrote: On Mon, Sep 29, 2014

Re: [PATCH] Redesign jump threading profile updates

it was too large. I suppose Teresa did receive it though. Not sure whether I can attach it in .xz format? Is this allowed? Thanks Christophe. Thanks, Sebastian -- Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413

Re: [PATCH] Redesign jump threading profile updates

On Wed, Oct 1, 2014 at 9:20 AM, H.J. Lu hjl.to...@gmail.com wrote: On Wed, Oct 1, 2014 at 8:29 AM, Teresa Johnson tejohn...@google.com wrote: I got the preprocessed source. With the aarch64 cross-compiler I built I am able to reproduce the ICE. Looking at it now. It may also cause: https

[PATCH] Fix PR63422 to handle profile insanities

regression tests for x86_64-unknown-linux-gnu. Ok for trunk if that passes? Thanks, Teresa 2014-10-01 Teresa Johnson tejohn...@google.com PR middle-end/63422 * tree-ssa-threadupdate.c (freqs_to_counts_path): Remove asserts to handle incoming insanities. Index: tree-ssa

Re: [PATCH] Redesign jump threading profile updates

the reported issue. Currently bootstrapping and testing on x86_64-unknown-linux-gnu. Ok for trunk if it passes? (The whitespace is getting messed up when I copy the patch in here - the indentations do line up in the patch.) Thanks, Teresa 2014-10-01 Teresa Johnson tejohn...@google.com * tree

Re: [PATCH] Redesign jump threading profile updates

On Wed, Oct 1, 2014 at 3:46 PM, Steve Ellcey sell...@mips.com wrote: On Wed, 2014-10-01 at 13:04 -0700, Teresa Johnson wrote: 2014-10-01 Teresa Johnson tejohn...@google.com * tree-ssa-threadupdate.c (freqs_to_counts_path): Scale frequencies up when synthesizing counts

Re: [PATCH] Redesign jump threading profile updates

issue. Currently bootstrapping and testing on x86_64-unknown-linux-gnu. Ok for trunk if it passes? (The whitespace is getting messed up when I copy the patch in here - the indentations do line up in the patch.) Thanks, Teresa 2014-10-01 Teresa Johnson tejohn...@google.com * tree

Re: [PATCH] Redesign jump threading profile updates

On Mon, Sep 29, 2014 at 9:33 PM, Jeff Law l...@redhat.com wrote: On 09/29/14 08:19, Teresa Johnson wrote: Just an update - I found some good test cases by compiling the c-torture tests with profile feedback with and without my patch. But in the cases I pulled out I saw that there were still

Re: [GOOGLE] Fix LIPO COMDAT fixup and gcov-tool interactions

On Tue, Sep 30, 2014 at 9:28 PM, Nathan Sidwell nat...@acm.org wrote: On 09/22/14 08:04, Teresa Johnson wrote: The approach we now take for LIPO builds is to propagate the counts LIPO? Sorry, Lightweight IPO (https://gcc.gnu.org/wiki/LightweightIpo), implemented and used on google branches

Re: [PATCH] Redesign jump threading profile updates

On Fri, Aug 1, 2014 at 10:10 PM, Teresa Johnson tejohn...@google.com wrote: On Wed, Jul 23, 2014 at 2:08 PM, Teresa Johnson tejohn...@google.com wrote: On Tue, Jul 22, 2014 at 7:29 PM, Jeff Law l...@redhat.com wrote: On 03/26/14 17:44, Teresa Johnson wrote: Recently I discovered

[GOOGLE] Fix new tests

does splitting. Ok for google branches? Teresa 2014-09-24 Teresa Johnson tejohn...@google.com * testsuite/gcc.dg/tree-prof/cold_partition_patch.c: * testsuite/g++.dg/tree-prof/partition_patch.C: Index: testsuite/gcc.dg/tree-prof/cold_partition_patch.c

Re: [GOOGLE] Fix new tests

if it is x86_64, otherwise it simply does splitting. Ok for google branches? Teresa 2014-09-24 Teresa Johnson tejohn...@google.com * testsuite/gcc.dg/tree-prof/cold_partition_patch.c: * testsuite/g++.dg/tree-prof/partition_patch.C: Index: testsuite/gcc.dg/tree-prof

[GOOGLE] Fix dynamic instrumentation patching for cold sections

tests. Ok for google branches? Thanks, Teresa 2014-09-23 Teresa Johnson tejohn...@google.com Google ref b/17608598. * config/i386/i386.c (ix86_output_function_nops_prologue_epilogue): Ensure we switch to correct section. * testsuite/gcc.dg/tree-prof

Re: [GOOGLE] Fix LIPO COMDAT fixup and gcov-tool interactions

be flagged in some way for downstream phases, but it is not a compilation mode we are using so I have not experimented. Thanks, Teresa nathan -- Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413

Re: [GOOGLE] Fix LIPO COMDAT fixup and gcov-tool interactions

-driver.cc (dyn_cgraph_node), which is where it is allocated. That routine does not have access to the dyn-ipa cgraph. Teresa David On Fri, Sep 12, 2014 at 4:31 PM, Teresa Johnson tejohn...@google.com wrote: This patch addresses issues when running gcov-tool after performing COMDAT fixup during

Re: [GOOGLE] Fix LIPO COMDAT fixup and gcov-tool interactions

as a bitvector as we do in the gcda file. Teresa David On Tue, Sep 16, 2014 at 7:57 AM, Teresa Johnson tejohn...@google.com wrote: On Mon, Sep 15, 2014 at 9:29 PM, Xinliang David Li davi...@google.com wrote: Is it necessary to declare zero_counts array at all? Can a flag field be added

[GOOGLE] Fix LIPO COMDAT fixup and gcov-tool interactions

the gcov-tool output (remove an overly-verbose output, make all output consistently go to stderr). Passes regression tests and manual tests. Ok for google branches? 2014-09-12 Teresa Johnson tejohn...@google.com * gcc/coverage.c (read_counts_file): Handle new section. * gcc/gcov.c

Re: [GOOGLE] Fix gcda build info support

one in gcov_exit_merge_gcda further down in the same file? Sure, I could outline that and pass in the gi_ptr for the merger case. Let me know if you meant something else. Teresa David On Wed, Sep 10, 2014 at 10:24 AM, Teresa Johnson tejohn...@google.com wrote: While porting recent support

Re: [GOOGLE] Fix gcda build info support

On Thu, Sep 11, 2014 at 10:17 AM, Xinliang David Li davi...@google.com wrote: Yes, that is what I meant. David On Thu, Sep 11, 2014 at 10:09 AM, Teresa Johnson tejohn...@google.com wrote: On Wed, Sep 10, 2014 at 3:31 PM, Xinliang David Li davi...@google.com wrote: Can you share

[GOOGLE] Fix gcda build info support

is the google/4_8 patch - I plan to commit there first then port it along with the original build info patch to 4_9. Passes regression tests - ok for google branches? Thanks, Teresa 2014-09-10 Teresa Johnson tejohn...@google.com libgcc: * libgcov-driver.c (gcov_scan_to_function_data): Rename

[GOOGLE] Fixup varpool references after LIPO linking

2014-08-28 Teresa Johnson tejohn...@google.com Google ref b/17038802. * l-ipo.c (resolve_cgraph_node): Pick non-external node. (fixup_reference_list): Fixup varpool references, remove old references, mark cgraph nodes as address taken as needed. Index: l-ipo.c

Re: [GOOGLE] Fixup varpool references after LIPO linking

node. The non-external node is a COMDAT, as as the comments in that routine indicate, COMDATs can be removed even if they are externally_visible. Teresa David On Thu, Aug 28, 2014 at 1:29 PM, Teresa Johnson tejohn...@google.com wrote: This patch fixes up varpool nodes after LIPO linking

[GOOGLE] Fix AutoFDO LIPO ICE due to eliminated abstract origin

to that in symtab_remove_unreachable_nodes. Tested with regression tests and internal benchmarks. Ok for google/4_9 2014-08-23 Teresa Johnson tejohn...@google.com Google ref b/16731481 * cgraphunit.c (analyze_functions): Don't remove origin node. Index: cgraphunit.c

[GOOGLE] Fix -fopt-info seg fault in AutoFDO LIPO mode

Fixes seg fault when using -fopt-info with AutoFDO LIPO. Ensure that the mapping between module name and ident is setup. Tested with regression tests and internal benchmarks. Ok for google/4_9 2014-08-23 Teresa Johnson tejohn...@google.com Google ref b/17124135 * auto

Re: [GOOGLE] Fix AutoFDO LIPO ICE due to eliminated abstract origin

the first does not cause any problems. Teresa On Sat, Aug 23, 2014 at 11:50 AM, Xinliang David Li davi...@google.com wrote: Is it a problem specific to LIPO? David On Sat, Aug 23, 2014 at 11:41 AM, Teresa Johnson tejohn...@google.com wrote: This patch ensures we don't prematurely delete

Re: [GOOGLE] Fix the bug where implicit section names prevents function splitting

(NODE)) Teresa + struct GTY(()) tree_decl_with_vis { struct tree_decl_with_rtl common; tree assembler_name; -- -- Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413

[Google/4_9] A couple gcov-tool fixes

, Teresa 2014-08-14 Teresa Johnson tejohn...@google.com * libgcov-merge.c (__gcov_merge_dc): Use gcov_get_counter, Relax the check after COMDAT fixup. (__gcov_merge_icall_topn): Use gcov_get_counter. Index: libgcov-merge.c

Re: [Google/4_9] A couple gcov-tool fixes

in libgcov.h and accesses should be through the new gcov_get_counter interface, but these just got missed when it was ported from trunk. Teresa David On Thu, Aug 14, 2014 at 11:27 AM, Teresa Johnson tejohn...@google.com wrote: Fix a couple problems found during testing. Backport from trunk

Re: [GOOGLE] Fix the bug where implicit section names prevents function splitting

at 11:25 AM, Teresa Johnson tejohn...@google.com wrote: On Wed, Aug 13, 2014 at 9:03 PM, Yi Yang ahyan...@google.com wrote: This bug is caused by my last patch, which did not differentiate between explicit section names (via attributes) and implicit section names (via -ffunction-section

Re: [GOOGLE] Do not partition the cold/hot sections of a function with section attribute

On Mon, Aug 11, 2014 at 1:44 PM, Yi Yang ahyan...@google.com wrote: I ported this to trunk. Shall I commit this patch to the Google 4_8/4_9 branches first? Ok with me. Teresa On Mon, Aug 11, 2014 at 12:46 PM, Teresa Johnson tejohn...@google.com wrote: Ok, thanks. This seems reasonable. Can

Re: [GOOGLE] Do not partition the cold/hot sections of a function with section attribute

. */ optimize_function_for_speed_p (cfun) !DECL_ONE_ONLY (current_function_decl) + !DECL_SECTION_NAME (current_function_decl) !user_defined_section_attribute); } -- Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413

Re: [GOOGLE] Do not partition the cold/hot sections of a function with section attribute

removing user_defined_section_attribute and simply check !DECL_SECTION_NAME (current_function_decl). On Mon, Aug 11, 2014 at 8:00 AM, Teresa Johnson tejohn...@google.com wrote: On Fri, Aug 8, 2014 at 3:22 PM, Yi Yang ahyan...@google.com wrote: Friendly ping. Sorry, was OOO. The solution

Re: [PATCH] Redesign jump threading profile updates

On Wed, Jul 23, 2014 at 2:08 PM, Teresa Johnson tejohn...@google.com wrote: On Tue, Jul 22, 2014 at 7:29 PM, Jeff Law l...@redhat.com wrote: On 03/26/14 17:44, Teresa Johnson wrote: Recently I discovered that the profile updates being performed by jump threading were incorrect in many cases

[GOOGLE] Use resolved node during AFDO vpt

AFDO invokes cgraph_node_for_asm during VPT to get the cgraph node for a callee. Use the resolved node so we don't add a reference to the un-resolved node after LIPO fixup. Passes regression tests and internal test. Ok for google/4_9? Thanks, Teresa 2014-07-23 Teresa Johnson tejohn

Re: [PATCH] Redesign jump threading profile updates

On Tue, Jul 22, 2014 at 7:29 PM, Jeff Law l...@redhat.com wrote: On 03/26/14 17:44, Teresa Johnson wrote: Recently I discovered that the profile updates being performed by jump threading were incorrect in many cases, particularly in the case where the threading path contains a joiner. Some

[GOOGLE] Rewrite FUNCTION_DECL references after LIPO linking

This patch will rewrite references to function decls in all statements after LIPO linking so that the subsequent cgraph rebuild will set up references correctly. Passes regression and internal testing. Ok for google/4_9? Thanks, Teresa 2014-07-15 Teresa Johnson tejohn...@google.com

Re: [PATCH] Handle more COMDAT profiling issues

probabilities during inlining). Patch is below. Bootstrapped and tested on x86-64-unknown-linux-gnu. Also tested on a profile-use build of SPEC cpu2006. Ok for trunk when stage 1 reopens? Thanks, Teresa 2014-02-12 Teresa Johnson tejohn...@google.com * graphite.c (graphite_finalize): Pass

Re: [PATCH] Redesign jump threading profile updates

Ping. Jeff, any update on when you can look at this? Thanks, Teresa On Tue, May 27, 2014 at 7:10 AM, Teresa Johnson tejohn...@google.com wrote: On Thu, Apr 17, 2014 at 6:23 AM, Teresa Johnson tejohn...@google.com wrote: On Wed, Apr 16, 2014 at 10:39 PM, Jeff Law l...@redhat.com wrote: On 03/26

[GOOGLE] Define libgcov interface for distinguishing -ftest-coverage from -fprofile-generate

branches? Thanks, Teresa 2014-07-02 Teresa Johnson tejohn...@google.com Google ref b/15378201. * gcc/tree-profile.c (gcov_test_coverage_decl): Declare. (tree_init_instrumentation): Initialize gcov_test_coverage_decl. * libgcc/libgcov-driver.c (__gcov_dummy_ref7

Re: [GOOGLE] Define libgcov interface for distinguishing -ftest-coverage from -fprofile-generate

it to this if you think that is clearer. Teresa David On Wed, Jul 2, 2014 at 12:55 PM, Teresa Johnson tejohn...@google.com wrote: The following patch adds support for a new libgcov interface, __gcov_profiling_enabled, that can be used by applications to determine whether a binary has been

Re: [GOOGLE] Define libgcov interface for distinguishing -ftest-coverage from -fprofile-generate

New patch below. Retested. Ok for google branches? Thanks, Teresa 2014-07-02 Teresa Johnson tejohn...@google.com Google ref b/15378201. * gcc/tree-profile.c (gcov_test_coverage_decl): Declare. (tree_init_instrumentation): Initialize gcov_test_coverage_decl

[GOOGLE] LIPO resolved node handling for inline clone references

clones. Passes regression tests. Ok for google/4_9? Teresa 2014-07-01 Teresa Johnson tejohn...@google.com Google ref b/15411384. * cgraphbuild.c (mark_address): Skip resolved node lookup in inline copies. Index: cgraphbuild.c

[PATCH] Improve -fdump-tree-all efficiency

, no patch: 10m30s -fdump-tree-all, my patch: 1m21s Bootstrapped and tested on x86_64-unknown-linux-gnu. Ok for trunk? Thanks, Teresa 2014-06-26 Teresa Johnson tejohn...@google.com * c-family/c-common.h (get_dump_info): Declare. * c-family/c-gimplify.c (c_genericize): Use saved dump

Re: [PATCH] Add missing -fdump-* options

On Thu, Jun 26, 2014 at 12:40 AM, Richard Biener richard.guent...@gmail.com wrote: On Wed, Jun 25, 2014 at 4:21 PM, Teresa Johnson tejohn...@google.com wrote: On Tue, May 13, 2014 at 8:19 AM, Xinliang David Li davi...@google.com wrote: On Tue, May 13, 2014 at 1:39 AM, Richard Biener

Re: [PATCH] Add missing -fdump-* options

On Tue, May 13, 2014 at 8:19 AM, Xinliang David Li davi...@google.com wrote: On Tue, May 13, 2014 at 1:39 AM, Richard Biener richard.guent...@gmail.com wrote: On Fri, May 9, 2014 at 5:54 PM, Teresa Johnson tejohn...@google.com wrote: I discovered that the support for the documented -fdump

[GOOGLE] Fix -femit-function-names in LIPO profile-use mode

Emit the proper module name in LIPO profile-use mode. Passes regression tests, ok for google branches? Thanks, Teresa 2014-06-24 Teresa Johnson tejohn...@google.com * coverage.c (emit_function_name): Emit module name in LIPO mode. Index: coverage.c

[Google] Fix AFDO early inline ICEs due to DFE

These two patches fix multiple ICE that occurred due to DFE being recently enabled after AutoFDO LIPO linking. Passes regression and internal testing. Ok for Google/4_8? Teresa 2014-06-12 Teresa Johnson tejohn...@google.com Dehao Chen de...@google.com Google ref b

  1   2   3   4   5   >