Re: [GOOGLE] Remove overly-aggressive LIPO assert

ok. David On Fri, Dec 4, 2015 at 11:29 AM, Teresa Johnson wrote: > 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

Re: [google gcc-4_9] Fix bad LIPO profile produced by gcov-tool

w I added the printing of both lengths. So now it is > also needed. > > On Tue, Dec 1, 2015 at 4:46 PM, Xinliang David Li <davi...@google.com> wrote: >> Not sure about this line: >> >> mod_info->combined_strlen = saved_compressed_len; >> >> This did not

Re: [google][gcc-4_9] encode and compress cc1 option strings in gcov_module_info

e.com> wrote: >> It's 1:3 to 1:4 in the programs I tested. But it really depends on how >> the options are used. I think your idea of using combined strlen works >> better. >> I just make the code a little clumsy but it does not cause any >> performance issue. >> &

Re: [google][gcc-4_9] encode and compress cc1 option strings in gcov_module_info

On Tue, Oct 6, 2015 at 9:26 AM, Rong Xu <x...@google.com> wrote: > On Mon, Oct 5, 2015 at 5:33 PM, Xinliang David Li <davi...@google.com> wrote: >>unsigned ggc_memory = gcov_read_unsigned (); >> + unsigned marker = 0, len = 0, k; >> + char *

Re: [google][gcc-4_9] encode and compress cc1 option strings in gcov_module_info

unsigned ggc_memory = gcov_read_unsigned (); + unsigned marker = 0, len = 0, k; + char **string_array, *saved_cc1_strings; + for (unsigned j = 0; j < 7; j++) Do not use hard coded number. Use the enum defined in coverage.c. +string_array[j] = xstrdup

Re: [google][gcc-4_9] Remove unused key field in gcov_fn_info

else { gfi_ptr = gi_ptr->functions[f_ix]; - if (gfi_ptr && gfi_ptr->key == gi_ptr) + if (gfi_ptr) length = GCOV_TAG_FUNCTION_LENGTH; - else -length = 0; } The removal of 'else' path seems wrong. David On

Re: [google][gcc-4_9] Remove unused key field in gcov_fn_info

ok. David On Tue, Sep 29, 2015 at 4:08 PM, Rong Xu <x...@google.com> wrote: > You are right. I attached the updated patch to this email. > > On Tue, Sep 29, 2015 at 3:10 PM, Xinliang David Li <davi...@google.com> wrote: >>else >> { >>

Re: Patch GCC for profile-func-internal-id=0 coverage-callback=1

coverage callback function is not in trunk. > > It's ok to submit to google/gcc-4_9 branch. > > Thanks, > > -Rong > > On Wed, Sep 2, 2015 at 10:01 AM, Matt Deeds <mattde...@google.com> wrote: >> >> Hello, Honza. David Li said you might be able to help me get t

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

ok. David On Fri, Aug 14, 2015 at 11:13 PM, Teresa Johnson tejohn...@google.com wrote: This patch resets the lambda scope based sequence numbering used to assign numbers to lambdas during parsing when we pop a module scope. This resets the numbering for subsequent modules imported during LIPO

Re: [PATCH, Google] Backport trunk patch r220860 to google/4.9 branch

ok. David On Wed, Jun 17, 2015 at 3:06 PM, Carrot Wei car...@google.com wrote: Hi In aarch64 backend of google/4.9 branch, the split pattern for insn aarch64_lshr_sisd_or_int_mode3 destroys one of the source operands, causes the later usage of the operand get a wrong value (google bug

Re: [PATCH, Google] Notify df framework when removing an insn in simplify-got

ok. David On Tue, Jun 9, 2015 at 4:46 PM, Carrot Wei car...@google.com wrote: Hi I forgot to notify df framework when I removed an insn, it caused df verification failure described in google bug b/16155462. The following patch passed regression test on arm qemu in both thumb and arm

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

On Tue, Jun 2, 2015 at 1:56 PM, Ramana Radhakrishnan ramana@googlemail.com wrote: On Tue, Jun 2, 2015 at 7:15 PM, Sriraman Tallam tmsri...@google.com wrote: On Mon, Jun 1, 2015 at 1:33 PM, Ramana Radhakrishnan ramana@googlemail.com wrote: On Mon, Jun 1, 2015 at 7:55 PM, Sriraman Tallam

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

We have -finstrument-functions-exclude-function-list=.. in GCC, though it is not using mangled names. David On Thu, May 21, 2015 at 2:58 PM, Jakub Jelinek ja...@redhat.com wrote: On Thu, May 21, 2015 at 10:51:50PM +0100, Pedro Alves wrote: On 05/21/2015 10:12 PM, Sriraman Tallam wrote: My

Re: [RFC] COMDAT Safe Module Level Multi versioning

Hm. But which options are unsafe? Also wouldn't it be better to simply _not_ have unsafe options produce comdats but always make local clones for them (thus emit the comdat with unsafe flags dropped)? Always localize comdat functions may lead to text size increase. It does not work if the

Re: [PATCH, GOOGLE] Backport patch r212222 to google 4.9 branch

ok. David On Wed, May 13, 2015 at 11:00 AM, Carrot Wei car...@google.com wrote: Hi The more strict devirtualization condition in this patch helps to fix google bug b/19872411. Bootstraped and regression tested on x86-64. OK for google 4.9 branch?

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

The use case proposed by Sri allows user to selectively eliminate PLT overhead for hot external calls only. In such scenarios, lazy binding won't be something matters to the user. David On Mon, May 4, 2015 at 7:45 AM, Michael Matz m...@suse.de wrote: Hi, On Thu, 30 Apr 2015, Sriraman Tallam

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

yes -- a full solution that supports lazy binding will be nice. David On Mon, May 4, 2015 at 9:58 AM, Michael Matz m...@suse.de wrote: Hi, On Mon, 4 May 2015, Xinliang David Li wrote: The use case proposed by Sri allows user to selectively eliminate PLT overhead for hot external calls only

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

yes -- it is good to turn this on by default in LTO mode without requiring user to specify the option. David On Fri, May 1, 2015 at 9:23 AM, H.J. Lu hjl.to...@gmail.com wrote: On Fri, May 1, 2015 at 9:19 AM, Xinliang David Li davi...@google.com wrote: On Fri, May 1, 2015 at 8:01 AM, Andi Kleen

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

On Fri, May 1, 2015 at 8:01 AM, Andi Kleen a...@firstfloor.org wrote: Sriraman Tallam tmsri...@google.com writes: This comes with caveats. This cannot be generally done for all functions marked extern as it is impossible for the compiler to say if a function is truly extern (defined in a

Re: [GOOGLE] Avoid calling walk_aliased_vdefs in O0 function

ok. On Mon, Mar 23, 2015 at 5:37 PM, Carrot Wei car...@google.com wrote: This patch fixes google internal bug b/19277289. It can only be reproduced in google 4.9 branch. In function param_change_prob, there is following function call walk_aliased_vdefs (refd, gimple_vuse (stmt),

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

++) +abort(); + A = NextTLSClass(); + SetTLSClass2(A); + if (current_tls2_-id != i++) +abort(); +} On Fri, Mar 20, 2015 at 8:15 AM, Teresa Johnson tejohn...@google.com wrote: 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

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

19, 2015 at 6:09 AM, Teresa Johnson tejohn...@google.com wrote: On Wed, Mar 18, 2015 at 9:25 PM, Xinliang David Li davi...@google.com wrote: get_local_tls_init_fn can be called from other contexts other than 'handle_tls_init' -- is the added new assertion safe ? In fact there is still

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

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 to be suppressed for aux module? No, we generate the wrapper in the aux module and use it to access the TLS variable

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

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. The method can be called for aux module -- the decl created will also

Re: [GOOGLE] Disable overflow warning of the offset

ok david On Thu, Feb 19, 2015 at 11:07 AM, Dehao Chen de...@google.com wrote: The offset overflow warning would cause build fails when function's start line is missing(0). Until the start line issues is fixed, we will suppress this warning. Testing on-going. OK for google-4_9? Thanks,

Re: [GOOGLE] Refine LIPO aux function removal

ok. David On Fri, Jan 2, 2015 at 10:19 PM, Teresa Johnson tejohn...@google.com wrote: Fixes a problem caused by my recent change to allow aux functions to be removed. They need to be kept until after LIPO linking/static promotion, since they affect the promoted names of any static variables

Re: [GOOGLE] Make LIPO aux function removal consistent

Ok (perhaps merge DECL_EXTERNAL and cgraph_is_aux_decl_external checks together). David On Mon, Dec 22, 2014 at 4:57 PM, Teresa Johnson tejohn...@google.com wrote: Ping. Teresa On Fri, Dec 19, 2014 at 5:40 PM, Teresa Johnson tejohn...@google.com wrote: Passes regression tests, ok for

Re: [Google] Port patch r215585 to Google/4.9 branch

The fix is already in upstream gcc-4.9 branch? If yes, we just need a merge. David On Tue, Dec 16, 2014 at 11:30 AM, Carrot Wei car...@google.com wrote: Hi In Google application we hit the same problem as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63341, so we also need the patch r215585

Re: [GOOGLE] Sync google-4_9 autofdo to trunk

ok. David On Tue, Dec 16, 2014 at 2:15 PM, Dehao Chen de...@google.com wrote: This patch syncs google-4_9 autofdo implementation to trunk (as much as possible). Bootstrapped and passed regression test and performance test. OK for google-4_9? Thanks, Dehao

Re: [GOOGLE] Do not promote indirect call for AutoFDO in the callee body definition is not available

Does it paper over the real bug? David On Tue, Dec 16, 2014 at 2:38 PM, Dehao Chen de...@google.com wrote: This patch fixes the bug for undefined symbol in AutoFDO build. Testing on going. OK for google-4_9 branch? Thanks, Dehao Index: gcc/auto-profile.c

Re: [GOOGLE] Do not promote indirect call for AutoFDO in the callee body definition is not available

reasonable because if callee's definition is not available, we should not promote the indirect call anyway. It depends. If there is a wrong DFE before the promotion, we will end up missing opportunities. David Dehao On Tue, Dec 16, 2014 at 2:45 PM, Xinliang David Li davi...@google.com wrote

Re: [GOOGLE] Fix AutoFDO size issue

PM, Xinliang David Li davi...@google.com wrote: On Thu, Nov 13, 2014 at 2:57 PM, Dehao Chen de...@google.com wrote: IIRC, AutoFDO the actual iteration for AutoFDO is mostly 3. But it should not harm to set max iter as 10. On Thu, Nov 13, 2014 at 2:51 PM, Xinliang David Li davi...@google.com

Re: [google gcc-4.9] FDO build for linux kernel

ok. (the way to detect kernel build looks unpolished, but there does not seem to be a consistent way of doing it. Some targets have kernel specific flags ..) On Thu, Nov 13, 2014 at 10:40 AM, Rong Xu x...@google.com wrote: Here is patch that ports our work on FDO linux kernel build support to

Re: [GOOGLE] Fix AutoFDO size issue

Is there a need to have 10 iterations of early inline for autofdo? David On Thu, Nov 13, 2014 at 2:25 PM, Dehao Chen de...@google.com wrote: In AutoFDO, we increase einline iterations. This could lead to extensive code bloat if we have recursive calls like: dtor() { destroy(node); }

Re: [GOOGLE] Fix AutoFDO size issue

After inline summary is recomputed, the large code growth problem will also be better controlled, right? David On Thu, Nov 13, 2014 at 2:48 PM, Xinliang David Li davi...@google.com wrote: Is there a need to have 10 iterations of early inline for autofdo? David On Thu, Nov 13, 2014 at 2:25

Re: [GOOGLE] Fix AutoFDO size issue

On Thu, Nov 13, 2014 at 2:57 PM, Dehao Chen de...@google.com wrote: IIRC, AutoFDO the actual iteration for AutoFDO is mostly 3. But it should not harm to set max iter as 10. On Thu, Nov 13, 2014 at 2:51 PM, Xinliang David Li davi...@google.com wrote: After inline summary is recomputed

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

missing test case? David On Wed, 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

Re: [GOOGLE] Fix LIPO resolved node reference fixup

wrote: On Fri, Oct 24, 2014 at 10:55 AM, Xinliang David Li davi...@google.com wrote: When orgin_addr == addr, is there a guarantee that this assert: gcc_assert (TREE_OPERAND (op,0) == addr); is always true? It should be, that is the assumption of the code that we are trying to enforce

Re: [google gcc-4_9] make ifunc support available for BIONIC

ok. David On Mon, Oct 27, 2014 at 11:04 AM, Rong Xu x...@google.com wrote: ifunc support is hard-coded as false for BIONIC. This patch removes this check and let configure decide whether it should have ifunc support. Thanks, -Rong

Re: [GOOGLE] Fix LIPO resolved node reference fixup

When orgin_addr == addr, is there a guarantee that this assert: gcc_assert (TREE_OPERAND (op,0) == addr); is always true? 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,

Re: [PATCH] AutoFDO patch for trunk

Can someone pre-approve the patch so that Dehao can check it in after basic testing? David On Wed, Oct 22, 2014 at 10:06 AM, David Edelsohn dje@gmail.com wrote: Rainer Orth writes: As Joseph is repeating over and over again, *nothing* must be included before config.h, and auto-profile.c

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

On Mon, Oct 20, 2014 at 1:32 AM, Richard Biener richard.guent...@gmail.com wrote: On Mon, Oct 20, 2014 at 12:02 AM, Xinliang David Li davi...@google.com wrote: On Sat, Oct 18, 2014 at 4:19 PM, Xinliang David Li davi...@google.com wrote: On Sat, Oct 18, 2014 at 3:27 PM, Jan Hubicka hubi

Re: [Google/gcc-4_9][PATCH][target/x86_64] PR 63538

Why removing the tree_code check? David On Mon, Oct 20, 2014 at 10:35 AM, Sriraman Tallam tmsri...@google.com wrote: Hi, This patch is under review for trunk GCC : https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01638.html. In the mean time, is this ok for google/gcc-4_9 branch?

Re: [Google/gcc-4_9][PATCH][target/x86_64] PR 63538

David Li davi...@google.com wrote: Why removing the tree_code check? The actual problem happens because STRING_CSTs (end up in .lrodata) are not set a far address as they dont match the VAR_DECL check here. Futher, ix86_in_large_data_p call has the TREE_CODE check to do the right thing so

Re: [Google/gcc-4_9][PATCH][target/x86_64] PR 63538

On Mon, Oct 20, 2014 at 11:59 AM, Sriraman Tallam tmsri...@google.com wrote: On Mon, Oct 20, 2014 at 10:51 AM, Andrew Pinski pins...@gmail.com wrote: On Mon, Oct 20, 2014 at 10:46 AM, Sriraman Tallam tmsri...@google.com wrote: On Mon, Oct 20, 2014 at 10:42 AM, Xinliang David Li davi

Re: [Google/gcc-4_9][PATCH][target/x86_64] PR 63538

ok (for google branch). David On Mon, Oct 20, 2014 at 1:44 PM, Sriraman Tallam tmsri...@google.com wrote: On Mon, Oct 20, 2014 at 12:59 PM, Xinliang David Li davi...@google.com wrote: On Mon, Oct 20, 2014 at 11:59 AM, Sriraman Tallam tmsri...@google.com wrote: On Mon, Oct 20, 2014 at 10

Re: [GOOGLE] Disable -fdevirtualize by default

On Sun, Oct 19, 2014 at 1:19 AM, Jan Hubicka hubi...@ucw.cz wrote: I am surprised you hit the size limits with 4.9 only - for quite some time we keep all virtual functions in callgarph until inlining. In fact 4.9 is first that works harder to drop them early (because I hit the problem

Re: [GOOGLE] Disable -fdevirtualize by default

It was in upstream 4.9 branch, but got reverted in r215061 to fix PR/61214 and PR/62224. David On Sun, Oct 19, 2014 at 1:21 AM, Jan Hubicka hubi...@ucw.cz wrote: Hi Honza, As David says, we will do some more experiments with the change you suggest and speculative devirtualization, but we

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

On Sat, Oct 18, 2014 at 4:19 PM, Xinliang David Li davi...@google.com wrote: On Sat, Oct 18, 2014 at 3:27 PM, Jan Hubicka hubi...@ucw.cz wrote: The difference in instrumentation runtime is huge -- as topn profiler is pretty expensive to run. With FDO, it is probably better to make early

Re: [GOOGLE] Disable -fdevirtualize by default

No, Google branch is not yet synced to 4.9 head. David On Sun, Oct 19, 2014 at 1:11 PM, Jan Hubicka hubi...@ucw.cz wrote: It was in upstream 4.9 branch, but got reverted in r215061 to fix PR/61214 and PR/62224. Was your tests done with this change or without? Honza

Re: [GOOGLE] Disable -fdevirtualize by default

ok. David On Sat, Oct 18, 2014 at 9:25 AM, Teresa Johnson tejohn...@google.com wrote: 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.

Re: [GOOGLE] Disable -fdevirtualize by default

Devirtualization needs more tuning to be usable internally. We have seen 1.6% size increase on average, but unnoticable performance improvement with this option on. I would rather use the size budget to make inliner more aggressive :) For instrumentation build, some of our builds will reach the

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

The difference in instrumentation runtime is huge -- as topn profiler is pretty expensive to run. With FDO, it is probably better to make early inlining more aggressive in order to get more context sensitive profiling. David On Sat, Oct 18, 2014 at 10:05 AM, Jan Hubicka hubi...@ucw.cz wrote:

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

ok. David On Sat, Oct 18, 2014 at 9:26 AM, Teresa Johnson tejohn...@google.com wrote: Increasing the number of early inliner iterations from 1 to 2 enables more indirect calls to be promoted/inlined before instrumentation. This in turn reduces the instrumentation overhead, particularly for

Re: [GOOGLE] Disable -fdevirtualize by default

On Sat, Oct 18, 2014 at 3:23 PM, Jan Hubicka hubi...@ucw.cz wrote: Devirtualization needs more tuning to be usable internally. We have seen 1.6% size increase on average, but unnoticable performance Does that happen with -fno-devirtualize-speculatively? Not sure -- I will do some experiment.

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

On Sat, Oct 18, 2014 at 3:27 PM, Jan Hubicka hubi...@ucw.cz wrote: The difference in instrumentation runtime is huge -- as topn profiler is pretty expensive to run. With FDO, it is probably better to make early inlining more aggressive in order to get more context sensitive profiling. I

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

On Sat, Oct 18, 2014 at 4:26 PM, Jan Hubicka hubi...@ucw.cz wrote: On Sat, Oct 18, 2014 at 3:27 PM, Jan Hubicka hubi...@ucw.cz wrote: The difference in instrumentation runtime is huge -- as topn profiler is pretty expensive to run. With FDO, it is probably better to make early inlining

Re: [GOOGLE] Disable -fdevirtualize by default

On Sat, Oct 18, 2014 at 4:22 PM, Jan Hubicka hubi...@ucw.cz wrote: The virtual functions will be emitted in some modules, right? If they are hot, they will be included with the auxiliary modules. Note that LIPO indirect call profile will point to the comdat copy that is picked by the linker

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

Ok if large tests pass. David On Thu, Oct 16, 2014 at 9:16 AM, Teresa Johnson tejohn...@google.com wrote: The following patch fixes a LIPO issue with a virtual implicitly instantiated destructor from an aux module that was needed when we devirtualized a call from the primary module, but it

Re: [GOOGLE] recalculate dominance before update_ssa in AutoFDO pass

Is it destroyed by value profile transformations? Can you move the dominance recomputing code closer to where it gets invalidated? David On Wed, Oct 15, 2014 at 10:37 AM, Dehao Chen de...@google.com wrote: This patch recalculates dominance info before update_ssa call in AutoFDO. This fixes bug

Re: [GOOGLE] recalculate dominance before update_ssa in AutoFDO pass

. */ if (execute_fixup_cfg () TODO_cleanup_cfg) Dehao On Wed, Oct 15, 2014 at 10:50 AM, Xinliang David Li davi...@google.com wrote: Is it destroyed by value profile transformations? Can you move the dominance recomputing code closer to where it gets invalidated? David On Wed, Oct 15, 2014

Re: [Patch] Fix PR61889 for the w64-mingw32 case

Honza, not sure if this patch is idea, but this will unblock mingw build problems. Can this one get in? thanks, David On Wed, Sep 24, 2014 at 8:22 AM, Rainer Emrich rai...@emrich-ebersheim.de wrote: The following patch fixes PR61889 for x86_64-w64-mingw32. Details can be found on

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

ok. David On Sun, Oct 12, 2014 at 2:59 PM, Teresa Johnson tejohn...@google.com wrote: Guard the new time profiling under a parameter, off by default for Google since it isn't used and the extra instrumentation was adding bloat. Enabled time profiling for two test cases that explicitly test

Re: [GOOGLE] Handle missing BINFO for LIPO

Ok (please also guard it with L_IPO_COMP_MODE). David On Tue, Oct 7, 2014 at 11:27 AM, Teresa Johnson tejohn...@google.com wrote: We may have missing BINFO on a type if that type is a builtin, since in LIPO mode we will reset builtin types to their original tree nodes before parsing

Re: [PATCH] Indirect-call topn targets profiler (instrumentation)

On Mon, Oct 6, 2014 at 11:22 AM, Jan Hubicka hubi...@ucw.cz wrote: Rong, Would be possible to use topn profiler to get resonale histograms for switch expansion, too? In that case it may make sense to have value version of it as well. The underlying topn_profiler can be used the same way as

Re: [PATCH] Indirect-call topn targets profiler (instrumentation)

On Mon, Oct 6, 2014 at 1:31 PM, Jan Hubicka hubi...@ucw.cz wrote: Yes. That's doable. I'm just not sure if top 2 entries are enough. I can see from your example that it will be useful for BBs having multiple case stmt. I suppose we want real histogram profiler here. I.e. something that is

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

This patch should be targeting trunk gcc? David On Fri, Oct 3, 2014 at 9:23 AM, Rong Xu x...@google.com wrote: Hi, This patch fixed a bug exposed in build kernel with fdo. We cannot simply overwrite the bb footer in emit_barrier_after_bb as the bb may already have a footer (in this case,

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

The name 'e' is used for both outer scope edge and inner scope one. This is confusing. David On Fri, Oct 3, 2014 at 9:27 AM, Teresa 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

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

oops -- misread it :) Ok. David On Fri, Oct 3, 2014 at 9:45 AM, Teresa Johnson tejohn...@google.com wrote: On Fri, Oct 3, 2014 at 9:31 AM, Xinliang David Li davi...@google.com wrote: The name 'e' is used for both outer scope edge and inner scope one. No, the declaration was moved from

Re: [PATCH] Fix PR63422 to handle profile insanities

Probably need to file a bug to track the copyrename2 problem. David On Wed, Oct 1, 2014 at 9:59 AM, Teresa Johnson tejohn...@google.com wrote: This patch removes some asserts my jump threading patch r215739 added. An upstream pass (copyrename2) is introducing some bogus profile counts, so we

Re: [Patch AArch64] Fix extended register width

On Wed, Oct 1, 2014 at 1:42 AM, Richard Earnshaw rearn...@arm.com wrote: On 30/09/14 21:30, Eric Christopher wrote: On Tue, Sep 30, 2014 at 5:57 AM, Marcus Shawcroft marcus.shawcr...@gmail.com wrote: On 22 September 2014 19:41, Carrot Wei car...@google.com wrote: Hi The extended register

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? See https://gcc.gnu.org/wiki/LightweightIpo It is a feature in google GCC branches. David for the

Re: [GOOGLE] Fix new tests

not sure if there is a better way, but ok. David On Wed, Sep 24, 2014 at 6:20 AM, Teresa Johnson tejohn...@google.com wrote: The new tests added for -mpatch-functions-for-instrumentation did not correctly restrict themselves to x86_64 since tree-prof.exp doesn't support dg-do. Work around

Re: [GOOGLE] Fix dynamic instrumentation patching for cold sections

ok. David On Tue, Sep 23, 2014 at 10:27 AM, Teresa Johnson tejohn...@google.com wrote: This patch fixes the support for patching for instrumentation so that it works with function splitting, by using the correct helper method for locating the current section. Added a couple tests cloned

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

On Mon, Sep 22, 2014 at 1:36 AM, Nathan Sidwell nat...@acm.org wrote: On 09/21/14 18:58, Xinliang David Li wrote: the intent is that that points to the gcov_info object of the object file containing the live version of the function. I couldn't quite get this to work though -- it involves

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

On Mon, Sep 22, 2014 at 8:04 AM, Teresa Johnson tejohn...@google.com wrote: On Mon, Sep 22, 2014 at 1:36 AM, Nathan Sidwell nat...@acm.org wrote: On 09/21/14 18:58, Xinliang David Li wrote: the intent is that that points to the gcov_info object of the object file containing the live version

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

On Sun, Sep 21, 2014 at 5:48 AM, Nathan Sidwell nat...@acm.org wrote: On 09/13/14 00:31, Teresa Johnson wrote: This patch addresses issues when running gcov-tool after performing COMDAT fixup during dyn-ipa. Functions that were previously all zero counts are marked, and the counts are

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

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 to dyn_cgraph_node structure to indicate if it is fixed up? The zero_counts array is used to pass info back to the caller in libgcov-driver.cc (dyn_cgraph_node

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

1.5M increase is not big concern. Ok with that. David On Tue, Sep 16, 2014 at 10:51 AM, Teresa Johnson tejohn...@google.com wrote: On Tue, Sep 16, 2014 at 8:07 AM, Xinliang David Li davi...@google.com wrote: The zero_counts array is passed to gcov_build_callgraph but not used until the dyn

Re: [google/gcc-4_9] Fix static var promotion handling for LIPO

ok. David On Mon, Sep 15, 2014 at 1:43 PM, Sharad Singhai sing...@google.com wrote: This patch is for the google/gcc-4_9 branch to fix a LIPO issue. This patch addresses handling for static initializer data during static variable promotion in LIPO optimize phase. This is useful for those

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

Is it necessary to declare zero_counts array at all? Can a flag field be added to dyn_cgraph_node structure to indicate if it is fixed up? 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

Re: [GOOGLE] Fix gcda build info support

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 the buildinfo reader code with the merger by defininig some hooks for different callbacks

Re: [GOOGLE] Fix gcda build info support

ok. David On Thu, Sep 11, 2014 at 11:49 AM, Teresa Johnson tejohn...@google.com wrote: 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

Re: [PATCH ARM] Fix PR target/63209

With gcc regression test, no regressions are found. David On Tue, Sep 9, 2014 at 11:45 AM, Xinliang David Li davi...@google.com wrote: Richard, thanks for the review. The revised patch is attached. Is this one OK (after testing is done)? David 2014-09-08 Xinliang David Li davi

Re: [PATCH ARM] Fix PR target/63209

Fixed the formatting and committed it to trunk: r215136. Will backport it to gcc-4_9 branch. thanks, David On Wed, Sep 10, 2014 at 11:24 AM, Richard Earnshaw rearn...@arm.com wrote: On 09/09/14 19:45, Xinliang David Li wrote: Richard, thanks for the review. The revised patch is attached

Re: [GOOGLE] Fix gcda build info support

Can you share the buildinfo reader code with the merger by defininig some hooks for different callbacks? David On Wed, Sep 10, 2014 at 10:24 AM, Teresa Johnson tejohn...@google.com wrote: While porting recent support for a build info section in the gcda from google/4_8 to 4_9 and doing manual

[PATCH ARM] Fix PR target/63209

=== --- ChangeLog (revision 215039) +++ ChangeLog (working copy) @@ -1,3 +1,9 @@ +2014-09-08 Xinliang David Li davi...@google.com + + PR target/63209 + * config/arm/arm.md (movcond_addsi_1): New pattern. + (movcond_addsi): Add a constraint

Re: [PATCH ARM] Fix PR target/63209

Richard, thanks for the review. The revised patch is attached. Is this one OK (after testing is done)? David 2014-09-08 Xinliang David Li davi...@google.com PR target/63209 * config/arm/arm.md (movcond_addsi): Handle case where source and target operands are the same

Re: [GOOGLE] Fixup varpool references after LIPO linking

ok. The patch is fine. On Thu, Aug 28, 2014 at 1:46 PM, Teresa Johnson tejohn...@google.com wrote: On Thu, Aug 28, 2014 at 1:40 PM, Xinliang David Li davi...@google.com wrote: Do you know why the previous check is not enough ? cgraph_can_remove_if_no_direct_calls_and_refs_p (struct

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

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 an abstract origin node, leading to creating a new one after LIPO linking when we invoke similar handling in

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

ok. David On Sat, Aug 23, 2014 at 11:42 AM, Teresa Johnson tejohn...@google.com wrote: 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

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

there is none. Trunk has the same code in these two locations, but the creation of a new node after deleting 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

Re: [GOOGLE, AUTOFDO] Assign different discriminators to calls with the same lineno

? David instead of where it is inserted. This is also problematic. Wei. On Thu, Aug 7, 2014 at 12:11 PM, Xinliang David Li davi...@google.com wrote: Is this [1.cc : 179:64] Reader::~Reader (version); from an inline instance? David On Wed, Aug 6, 2014 at 10:18 AM, Wei Mi w...@google.com

Re: another gcov cleanup

looks good. thanks. David On Sat, Jul 26, 2014 at 12:08 AM, Nathan Sidwell nat...@acm.org wrote: This patch removes 2 global variables -- gi_filename and gcov_max_filename. The relevant data is moved into the renamed gcov_filename structure and length is calculated later in the process. One

Re: FDO and source changes

Ok. The internal benchmark testing also shows no change in behavior. David On Fri, Jul 25, 2014 at 2:55 PM, Jeff Law l...@redhat.com wrote: On 07/23/14 15:52, Xinliang David Li wrote: Index: ChangeLog === --- ChangeLog

Re: gcov name cleanup

On Wed, Jul 23, 2014 at 11:45 PM, Nathan Sidwell nat...@acm.org wrote: This second patch cleans up some more global names. the three functions should not be visible to the user. I'm not sure if they're attempting to export an interface to the user but they're (a) undocumented and (b) don't

Re: FDO and source changes

On Tue, Jul 22, 2014 at 8:14 PM, Jeff Law l...@redhat.com wrote: On 07/16/14 14:32, Xinliang David Li wrote: Instrumentation based FDO is designed to work when the source files that are used to generate the instr binary match exactly with the sources in profile-use compile. It is known

Re: FDO and source changes

crc32 to something that's 64 bit long is enough to make sure collisions does not happen. Maybe it's worth the trouble? On Wed, Jul 23, 2014 at 10:42 AM, Xinliang David Li davi...@google.com wrote: On Tue, Jul 22, 2014 at 8:14 PM, Jeff Law l...@redhat.com wrote: On 07/16/14 14:32, Xinliang

Re: [GOOGLE] Use resolved node during AFDO vpt

ok. David On Wed, Jul 23, 2014 at 1:46 PM, Teresa Johnson tejohn...@google.com wrote: 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

Re: FDO and source changes

-insns-in-bb, Index: ChangeLog === --- ChangeLog (revision 212682) +++ ChangeLog (working copy) @@ -1,3 +1,10 @@ +2014-07-16 Xinliang David Li davi...@google.com + + * params.def: New parameter. + * coverage.c

  1   2   3   4   5   6   7   8   9   10   >