Re: [GOOGLE] Remove overly-aggressive LIPO assert

Ping. Thanks, Teresa On Wed, Dec 2, 2015 at 12:46 PM, Teresa Johnson 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 after the LIPO link due to

[GOOGLE] Remove overly-aggressive LIPO assert

regression tests. Ok for Google branch? 2015-12-02 Teresa Johnson Google ref b/25925223. * l-ipo.c (cgraph_lipo_get_resolved_node_1): Remove overly-strict assert. Index: l-ipo.c === --- l-ipo.c (revision 231131) +++ l-ipo.c

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

: > > 2015-10-26 Renlin Li > > * 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 Google ref b/24569916 * params.def (PARAM_MAX_VARTRACK_SIZE): Reduce default to 40M. Index: params.def

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

-25 Teresa Johnson 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 wasn't explicitly set.

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 wrote: > Teresa Johnson writes: > >> This patch unsets -freorder-blocks-and-partition when -fprofile-use >> is not specified. Function

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

t 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 >> >> > >

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 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 being performed >> in that case, as p

[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 * opts.c (finish_options): Unset -freorder-blocks-and

[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 Google ref b/23176787. * cp/cp-lang.c: Rename clear_deferred_fns to reset_parsing_state. * cp/cp-tree.h: Ditto, declare

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 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 testing. Ok f

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

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

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

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

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

dentally 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 wrote: >> On Thu, Mar 19, 2015 at 4:45 PM, Xinliang David Li >> wrote: >>> does generate_tls_wr

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

ule). Teresa > > David > > On Thu, Mar 19, 2015 at 4:11 PM, Teresa Johnson wrote: >> New patch below. Passes regression tests plus internal application build. >> >> 2015-03-19 Teresa Johnson >> >> gcc/ >> Google ref b/19618364. &

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 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 if necessary

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

he 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 > wrote: >> >> Ensure TLS variable wrapper and init functions are recorded at >> the module scope upon

[GOOGLE] Refine LIPO aux function removal

? Thanks, Teresa 2015-01-02 Teresa Johnson 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 === --- cgraph.c

Re: [GOOGLE] Make LIPO aux function removal consistent

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

[GOOGLE] Make LIPO aux function removal consistent

Passes regression tests, ok for google 4_9? Thanks, Teresa 2014-12-19 Teresa Johnson 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: cgraph.c

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

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

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

On Thu, Nov 13, 2014 at 12:55 PM, Jakub Jelinek 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 wrote: >> > On Thu, Nov 13, 2014 at 7:12 AM, Jakub Jelinek wrote: >> >> And for release branc

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

On Thu, Nov 13, 2014 at 7:39 AM, Teresa Johnson wrote: > On Thu, Nov 13, 2014 at 7:12 AM, Jakub Jelinek 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, > will also

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

On Thu, Nov 13, 2014 at 7:12 AM, Jakub Jelinek 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,

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

On Thu, Nov 13, 2014 at 6:36 AM, Jakub Jelinek 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 >> >>

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

On Thu, Nov 13, 2014 at 6:32 AM, Richard Biener wrote: > On Thu, Nov 13, 2014 at 3:32 PM, Richard Biener > wrote: >> On Thu, Nov 13, 2014 at 3:20 PM, Teresa Johnson wrote: >>> Here is the new patch. Bootstrapped and tested on >>> x86_64-unknown-linux-gnu. OK for

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

return good != bad; +} On Wed, Nov 12, 2014 at 9:40 PM, Andrew Pinski wrote: > On Wed, Nov 12, 2014 at 9:38 PM, Teresa Johnson wrote: >> On Wed, Nov 12, 2014 at 9:30 PM, Andrew Pinski wrote: >>> On Wed, Nov 12, 2014 at 9:25 PM, Teresa Johnson >>> wrote: >>>>

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

On Wed, Nov 12, 2014 at 9:30 PM, Andrew Pinski wrote: > On Wed, Nov 12, 2014 at 9:25 PM, Teresa Johnson wrote: >> Added testcase. Here is the new patch: >> >> 2014-11-12 >> >> gcc: >> PR tree-optimization/63841 >> * tree.c (initi

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

nitializer_zerop (const_tree init) >>{ >> unsigned HOST_WIDE_INT idx; >> >> + if (!CONSTRUCTOR_NELTS (init)) >> + return false; >> FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (init), idx, elt) >> if (!initializer_zerop (elt)) >> return false; >> >> >> -- >> Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413 -- Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413

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

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

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 wrote: > On 06/11/14 18:07, Renlin Li wrote: >> >> On 06/11/14 17:59, Teresa Johnson wrot

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

e-elf toolchain has been test on the model. No new regression. > > gcc/ChangeLog: > > 2014-11-06 Renlin Li > PR middle-end/61529 > * tree-ssa-threadupdate.c (compute_path_counts): Bound path_in_freq. > This is needed due to insane incoming frequencies. > &g

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

> >> On 11/03/14 08:29, Renlin Li 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

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

; > gcc/ChangeLog: > > 2014-10-29 Renlin Li > PR 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 Google ref b/18110567. * cgraphbuild.c (fixup_all_refs_1): New function

Re: [GOOGLE] Fix LIPO resolved node reference fixup

assert. Teresa > > David > > > > On Fri, Oct 24, 2014 at 10:21 AM, Teresa Johnson 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

[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

Re: [GOOGLE] Disable -fdevirtualize by default

; >> > calls and thus more topn profiling) you may consider just hacking >> >> > ipa.c:walk_polymorphic_call_targets to not make the possible targets as >> >> > reachable. (see the conditional on before_inlining_p). >> >> > >> >> > Of course this will get you less devirtualization (but with LTO 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 | tejohn...@google.com | 408-460-2413

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

ect calls to be promoted/inlined before instrumentation. This in >> >> >> turn >> >> >> reduces the instrumentation overhead, particularly for more expensive >> >> >> indirect >> >> >> call topn profiling. >> >> &g

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

. Ok for google/4_9? 2014-10-18 Teresa Johnson 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 === --- opts.c

[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] Treat artificial from aux modules as non-external

, passes regression tests. Ok for google/4_9? Thanks, Teresa 2014-10-16 Teresa Johnson 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

tested on x86_64-unknown-linux-gnu. Ok for trunk? Thanks, Teresa 2014-10-14 Teresa Johnson 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

Callgraph group : _Z3foov _Z3barv main Passes regression tests. Ok for google/4_9? 2014-10-12 Teresa Johnson 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:

[PATCH] Fix PR bootstrap/63432 in jump threading

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

[GOOGLE] Handle missing BINFO for LIPO

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

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

On Fri, Oct 3, 2014 at 9:31 AM, Xinliang David Li wrote: > The name 'e' is used for both outer scope edge and inner scope one. No, the declaration was moved from the inner scope to the outer scope. Teresa > This is confusing. > > David > > > On Fri, Oct 3,

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

(in this case, a deleted label stmt). >> 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

[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 Google ref b/173

Re: [PATCH] Fix PR63422 to handle profile insanities

On Wed, Oct 1, 2014 at 10:03 AM, Xinliang David Li 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 wrote: >&g

Re: [PATCH] Redesign jump threading profile updates

On Thu, Oct 2, 2014 at 8:45 AM, Steve Ellcey 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 >> als

Re: [PATCH] Redesign jump threading profile updates

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

Re: [PATCH] Redesign jump threading profile updates

s 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 - >> th

Re: [PATCH] Redesign jump threading profile updates

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

Re: [PATCH] Redesign jump threading profile updates

s 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 * tree-ssa-threadupd

[PATCH] Fix PR63422 to handle profile insanities

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

Re: [PATCH] Redesign jump threading profile updates

On Wed, Oct 1, 2014 at 9:20 AM, H.J. Lu wrote: > On Wed, Oct 1, 2014 at 8:29 AM, Teresa Johnson 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: > > h

Re: [PATCH] Redesign jump threading profile updates

preprocessed source if appropriate. >>> Please include the complete backtrace with any bug report. >>> See <http://gcc.gnu.org/bugs.html> for instructions. >>> >>> Can you have a look? >> >> It would help if you could attach a preprocessed file. >> > I did it in a followup mail, but the list server rejected it because > 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 6:20 AM, Teresa Johnson wrote: > Sorry, yes, will try to reproduce. > Teresa > > On Wed, Oct 1, 2014 at 12:03 AM, Christophe Lyon > wrote: >> On 30 September 2014 20:20, Teresa Johnson wrote: >>> On Mon, Sep 29, 2014 at 9:33 PM, Jeff Law

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 wrote: > On 30 September 2014 20:20, Teresa Johnson wrote: >> On Mon, Sep 29, 2014 at 9:33 PM, Jeff Law wrote: >>> On 09/29/14 08:19, Teresa Johnson wrote: >>>>> >>

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

On Tue, Sep 30, 2014 at 9:28 PM, Nathan Sidwell 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 use

Re: [PATCH] Redesign jump threading profile updates

On Mon, Sep 29, 2014 at 9:33 PM, Jeff Law 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 th

Re: [PATCH] Redesign jump threading profile updates

On Fri, Aug 1, 2014 at 10:10 PM, Teresa Johnson wrote: > On Wed, Jul 23, 2014 at 2:08 PM, Teresa Johnson wrote: >> On Tue, Jul 22, 2014 at 7:29 PM, Jeff Law wrote: >>> On 03/26/14 17:44, Teresa Johnson wrote: >>>> >>>> Recently I discovered that t

Re: [GOOGLE] Fix new tests

On Wed, Sep 24, 2014 at 8:23 AM, Xinliang David Li wrote: > not sure if there is a better way, but ok. I looked through the documentation and other tests last night, but couldn't come up with a better way unfortunately. Teresa > > David > > On Wed, Sep 24, 2014 at 6:2

[GOOGLE] Fix new tests

imply does splitting. Ok for google branches? Teresa 2014-09-24 Teresa Johnson * 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_pa

[GOOGLE] Fix dynamic instrumentation patching for cold sections

tests. Ok for google branches? Thanks, Teresa 2014-09-23 Teresa Johnson 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/cold_partition_patch.c: New test

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

doing any analysis), and gcov-dump will flag them. My patch does not do anything special for these routines when they are read into the profile-use build, because we do want the propagated counts during optimization. Possibly in whole-program mode they should be cleared on read just as in gcov-tool, or they could 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

itvector as we do in the gcda file. Teresa > > David > > On Tue, Sep 16, 2014 at 7:57 AM, Teresa Johnson wrote: >> On Mon, Sep 15, 2014 at 9:29 PM, Xinliang David Li >> wrote: >>> Is it necessary to declare zero_counts array at all? Can a flag field >>&

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

ver.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 wrote: >> This patch addresses issues when running gcov-tool after performing >> COMDAT fixup durin

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

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 * gcc/coverage.c (read_counts_file): Handle new section. * gcc/gcov.c (read_count_file

Re: [GOOGLE] Fix gcda build info support

On Thu, Sep 11, 2014 at 10:17 AM, Xinliang David Li wrote: > Yes, that is what I meant. > > David > > On Thu, Sep 11, 2014 at 10:09 AM, Teresa Johnson wrote: >> On Wed, Sep 10, 2014 at 3:31 PM, Xinliang David Li >> wrote: >>> Can you share the buildinfo read

Re: [GOOGLE] Fix gcda build info support

existing 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 wrote: >> While porting recent suppo

[GOOGLE] Fix gcda build info support

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 libgcc: * libgcov-driver.c (gcov_scan_to_function_data): Rename from

Re: [GOOGLE] Fixup varpool references after LIPO linking

ode. 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 > wrote: >> >> This patch fixes up varpool nodes

[GOOGLE] Fixup varpool references after LIPO linking

2014-08-28 Teresa Johnson 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] 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 wrote: > Is it a problem specific to LIPO? > > David > > On Sat, Aug 23, 2014 at 11:41 AM, Teresa Johnson wrote: >> This patch ensures we don't prematurely delete an abstrac

[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 Google ref b/17124135 * auto-profile.c (read_aux_modules

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

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

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

!= NULL_TREE \ > + && !DECL_HAS_IMPLICIT_SECTION_NAME_P(NODE)) > + > extern tree decl_debug_expr_lookup (tree); > extern void decl_debug_expr_insert (tree, tree); > > -- > > On Thu, Aug 14, 2014 at 11:25 AM, Teresa Johnson wrote: >> On Wed, Aug 13, 2014 at 9:0

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

n 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 > wrote: >> >> Fix a couple problems found during tes

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

, Teresa 2014-08-14 Teresa Johnson * 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] Fix the bug where implicit section names prevents function splitting

sonally, I think it is clearer to simply write this as: #define DECL_HAS_EXPLICIT_SECTION_NAME_P(NODE) \ (DECL_SECTION_NAME(NODE) != NULL_TREE \ && !DECL_HAS_IMPLICIT_SECTION_NAME_P(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

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 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 wrote: >> Ok, thanks. This seems reasonable. Can you send

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

ing user_defined_section_attribute) >>resetting (user_defined_section_attribute = false) >> } >> >> But now GCC works this way: >> >> for each function { >>parse into tree (setting user_defined_section_attribute) >> } >> do IPA passes >> for each

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

t; > index fa6f62f..09449c6 100644 >> > --- gcc/bb-reorder.c >> > +++ gcc/bb-reorder.c >> > @@ -2555,6 +2555,7 @@ gate_handle_partition_blocks (void) >> > we are going to omit the reordering. */ >> >&& 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: [PATCH] Redesign jump threading profile updates

On Wed, Jul 23, 2014 at 2:08 PM, Teresa Johnson wrote: > On Tue, Jul 22, 2014 at 7:29 PM, Jeff Law wrote: >> On 03/26/14 17:44, Teresa Johnson wrote: >>> >>> Recently I discovered that the profile updates being performed by jump >>> threading were incorrec

Re: [PATCH] Redesign jump threading profile updates

On Tue, Jul 22, 2014 at 7:29 PM, Jeff Law 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 con

[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 G

[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 Google ref b/16190119

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 wrote: > On Thu, Apr 17, 2014 at 6:23 AM, Teresa Johnson wrote: >> On Wed, Apr 16, 2014 at 10:39 PM, Jeff Law wrote: >>> On 03/26/14 17:44, Te

Re: [PATCH] Handle more COMDAT profiling issues

e->count; > +call_count += cgraph_function_with_gimple_body_p (e->caller) > + ? gimple_bb (e->call_stmt)->count : 0; > > I am quite confused by this change - we you don't want to trust edge counts? > Other parts of the patch seems quite resonable, but I don't really follow > here. It is because we are invoking this before rebuilding the cgraph. Here is the comment to this effect that I added just above handle_missing_profiles: + This is now invoked before rebuilding the cgraph after reading profile + counts, so the cgraph edge and node counts are still 0. Therefore we + need to look at the counts on the entry bbs and the call stmt bbs. + That way we can avoid needing to rebuild the cgraph again to reflect + the nodes with dropped profiles. */ Thanks, Teresa > > Honza -- Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413

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 Google ref b/15378201. * gcc/tree-profile.c (gcov_test_coverage_decl): Declare. (tree_init_instrumentation): Initialize gcov_test_coverage_decl. * libgcc/libgcov

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

e it to this if you think that is clearer. Teresa > > David > > > On Wed, Jul 2, 2014 at 12:55 PM, Teresa Johnson wrote: >> The following patch adds support for a new libgcov interface, >> __gcov_profiling_enabled, that can be used by applications to >> determine whet

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

branches? Thanks, Teresa 2014-07-02 Teresa Johnson 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): Define

[GOOGLE] LIPO resolved node handling for inline clone references

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

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

On Thu, Jun 26, 2014 at 12:40 AM, Richard Biener wrote: > On Wed, Jun 25, 2014 at 4:21 PM, Teresa Johnson wrote: >> On Tue, May 13, 2014 at 8:19 AM, Xinliang David Li >> wrote: >>> On Tue, May 13, 2014 at 1:39 AM, Richard Biener >>> wrote: >>>> O

[PATCH] Improve -fdump-tree-all efficiency

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 * c-family/c-common.h (get_dump_info): Declare. * c-family/c-gimplify.c (c_genericize): Use saved dump files. * c

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

On Tue, May 13, 2014 at 8:19 AM, Xinliang David Li wrote: > On Tue, May 13, 2014 at 1:39 AM, Richard Biener > wrote: >> On Fri, May 9, 2014 at 5:54 PM, Teresa Johnson wrote: >>> I discovered that the support for the documented -fdump-* options >>> "optimized&

[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 * 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 Dehao Chen Google ref b/15521327. * cgraphclones.c

  1   2   3   4   5   6   >