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 prior assert. In this case we had a hidden visib
both lengths. So now it is
> also needed.
>
> On Tue, Dec 1, 2015 at 4:46 PM, Xinliang David Li wrote:
>> Not sure about this line:
>>
>> mod_info->combined_strlen = saved_compressed_len;
>>
>> This did not exist for the compiler path before.
>>
>
> 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.
>>
>> On Tue,
On Tue, Oct 6, 2015 at 9:26 AM, Rong Xu wrote:
> On Mon, Oct 5, 2015 at 5:33 PM, Xinliang David Li wrote:
>>unsigned ggc_memory = gcov_read_unsigned ();
>> + unsigned marker = 0, len = 0, k;
>> + char **string_array, *saved_cc1_strings;
>> +
>>
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 (gcov_read_s
ok.
David
On Tue, Sep 29, 2015 at 4:08 PM, Rong Xu wrote:
> You are right. I attached the updated patch to this email.
>
> On Tue, Sep 29, 2015 at 3:10 PM, Xinliang David Li wrote:
>>else
>> {
>>gfi_ptr = gi_ptr->functions[f_
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 Tue
Sorry for the wrong advice. I thought the feature was in trunk. Rong,
can you submit the callback support to trunk?
David
On Wed, Sep 2, 2015 at 1:41 PM, Rong Xu wrote:
> Matt,
>
> It seems this patch is for google branch, rather the trunk. The code for
> coverage callback function is not in tr
ok.
David
On Fri, Aug 14, 2015 at 11:13 PM, Teresa Johnson 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 compilation.
>
>
ok.
David
On Wed, Jun 17, 2015 at 3:06 PM, Carrot Wei wrote:
> Hi
>
> In aarch64 backend of google/4.9 branch, the split pattern for insn
> aarch64_lshr_sisd_or_int_3 destroys one of the source operands,
> causes the later usage of the operand get a wrong value (google bug
> 17907351).
>
> The b
ok.
David
On Tue, Jun 9, 2015 at 4:46 PM, Carrot Wei 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 modes.
> OK for
On Tue, Jun 2, 2015 at 1:56 PM, Ramana Radhakrishnan
wrote:
> On Tue, Jun 2, 2015 at 7:15 PM, Sriraman Tallam wrote:
>> On Mon, Jun 1, 2015 at 1:33 PM, Ramana Radhakrishnan
>> wrote:
>>> On Mon, Jun 1, 2015 at 7:55 PM, Sriraman Tallam wrote:
On Mon, Jun 1, 2015 at 11:41 AM, Ramana Radhakri
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 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 original
>
> 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
ok.
David
On Wed, May 13, 2015 at 11:00 AM, Carrot Wei 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?
yes -- a full solution that supports lazy binding will be nice.
David
On Mon, May 4, 2015 at 9:58 AM, Michael Matz 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
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 wrote:
> Hi,
>
> On Thu, 30 Apr 2015, Sriraman Tallam wrote:
>
>>
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 wrote:
> On Fri, May 1, 2015 at 9:19 AM, Xinliang David Li wrote:
>> On Fri, May 1, 2015 at 8:01 AM, Andi Kleen wrote:
>>&g
On Fri, May 1, 2015 at 8:01 AM, Andi Kleen wrote:
> Sriraman Tallam 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 shared library). If a
>> funct
ok.
On Mon, Mar 23, 2015 at 5:37 PM, Carrot Wei 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), record_modified, &info
suite/g++.dg/tree-prof/lipo/tls_1.C (working copy)
> @@ -0,0 +1,38 @@
> +// { dg-options "-std=c++11 -O2 --param=lipo-sampling-period=1" }
> +#include
> +#include
> +#include
> +#include "tls.h"
> +TLSClass* NextTLSClass() {
> + return new TLSClas
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
>> method can be called for aux module -- the decl created will also be
>> promoted.
>
at 5:51 PM, Teresa Johnson wrote:
> On Thu, Mar 19, 2015 at 4:45 PM, Xinliang David Li 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 and invoke it's
> ===
> --- testsuite/g++.dg/tree-prof/lipo/tls_1.C (revision 0)
> +++ testsuite/g++.dg/tree-prof/lipo/tls_1.C (working copy)
> @@ -0,0 +1,32 @@
> +// { dg-options "-std=c++11 -O2 --param=lipo-sampling-peri
ok
david
On Thu, Feb 19, 2015 at 11:07 AM, Dehao Chen 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,
> Dehao
>
> I
ok.
David
On Fri, Jan 2, 2015 at 10:19 PM, Teresa Johnson 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 defined within th
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 wrote:
> Ping.
> Teresa
>
> On Fri, Dec 19, 2014 at 5:40 PM, Teresa Johnson wrote:
>> Passes regression tests, ok for google 4_9?
>>
>> Thanks,
>> Teresa
>>
>
lem, but is also 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
Does it paper over the real bug?
David
On Tue, Dec 16, 2014 at 2:38 PM, Dehao Chen 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
>
ok.
David
On Tue, Dec 16, 2014 at 2:15 PM, Dehao Chen 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
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 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 for Google/4.
>> We do not do sophisticated recursive call detection in einline phase.
>> It only happens in ipa-inline phase.
>>
>> Dehao
>>
>> On Thu, Nov 13, 2014 at 3:18 PM, Xinliang David Li
>> wrote:
>>> On Thu, Nov 13, 2014 at 2:57 PM, Dehao Chen
On Thu, Nov 13, 2014 at 2:57 PM, Dehao Chen 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 wrote:
>> After inline summary is recomputed, the larg
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 wrote:
> Is there a need to have 10 iterations of early inline for autofdo?
>
> David
>
> On Thu, Nov 13, 2014 at 2:25
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 wrote:
> In AutoFDO, we increase einline iterations. This could lead to
> extensive code bloat if we have recursive calls like:
>
> dtor() {
> destroy(node);
> }
>
> destroy(nod
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 wrote:
> Here is patch that ports our work on FDO linux kernel build support to
> gcc-4_9. With
missing test case?
David
On Wed, Nov 12, 2014 at 2:13 PM, Teresa Johnson 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
> st
ok.
David
On Mon, Oct 27, 2014 at 11:04 AM, Rong Xu 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
tains ADDR and update it to the real callee's decl. */
> + fixup_decl_info info;
> + info.orig_decl = addr;
> + info.new_decl = real_callee->decl;
> + fixup_all_refs (&op, &info);
> }
>return false;
> }
>
>
> On Fri, Oct 24,
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 wrote:
> This patch makes a fix to the reference fixups performed after LIPO
> node resolution, to better handle t
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 wrote:
>> Rainer Orth writes:
>
>> As Joseph is repeating over and over again, *nothing* must be included
>> before config.h, and auto-profile.c violate
ok (for google branch).
David
On Mon, Oct 20, 2014 at 1:44 PM, Sriraman Tallam wrote:
> On Mon, Oct 20, 2014 at 12:59 PM, Xinliang David Li
> wrote:
>> On Mon, Oct 20, 2014 at 11:59 AM, Sriraman Tallam
>> wrote:
>>> On Mon, Oct 20, 2014 at 10:51 AM, Andrew Pinski
On Mon, Oct 20, 2014 at 11:59 AM, Sriraman Tallam wrote:
> On Mon, Oct 20, 2014 at 10:51 AM, Andrew Pinski wrote:
>> On Mon, Oct 20, 2014 at 10:46 AM, Sriraman Tallam
>> wrote:
>>> On Mon, Oct 20, 2014 at 10:42 AM, Xinliang David Li
>>> wrote:
>
Perhaps explicitly allowing STRING_CST to go through the large data
check, instead of removing the var-decl check? Do you see other
opcodes that need to be handled too?
David
On Mon, Oct 20, 2014 at 10:46 AM, Sriraman Tallam wrote:
> On Mon, Oct 20, 2014 at 10:42 AM, Xinliang David Li
>
Why removing the tree_code check?
David
On Mon, Oct 20, 2014 at 10:35 AM, Sriraman Tallam 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? Without
> this, -m
On Mon, Oct 20, 2014 at 1:32 AM, Richard Biener
wrote:
> On Mon, Oct 20, 2014 at 12:02 AM, Xinliang David Li
> wrote:
>> On Sat, Oct 18, 2014 at 4:19 PM, Xinliang David Li
>> wrote:
>>> On Sat, Oct 18, 2014 at 3:27 PM, Jan Hubicka wrote:
>>>>> Th
On Sat, Oct 18, 2014 at 4:19 PM, Xinliang David Li wrote:
> On Sat, Oct 18, 2014 at 3:27 PM, Jan Hubicka wrote:
>>> The difference in instrumentation runtime is huge -- as topn profiler
>>> is pretty expensive to run.
>>>
>>> With FDO, it is probably better
No, Google branch is not yet synced to 4.9 head.
David
On Sun, Oct 19, 2014 at 1:11 PM, Jan Hubicka 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
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 wrote:
>> Hi Honza,
>>
>> As David says, we will do some more experiments with the change you
>> suggest and speculative devirtualization, but we needed to
On Sun, Oct 19, 2014 at 1:19 AM, Jan Hubicka 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 w
On Sat, Oct 18, 2014 at 4:22 PM, Jan Hubicka 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 in the
On Sat, Oct 18, 2014 at 4:26 PM, Jan Hubicka wrote:
>> On Sat, Oct 18, 2014 at 3:27 PM, Jan Hubicka 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 aggressi
On Sat, Oct 18, 2014 at 3:27 PM, Jan Hubicka 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 agree
On Sat, Oct 18, 2014 at 3:23 PM, Jan Hubicka 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.
>> imp
ok.
David
On Sat, Oct 18, 2014 at 9:26 AM, Teresa Johnson 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 more expensive indir
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 wrote:
>> Increasing the
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 bu
ok.
David
On Sat, Oct 18, 2014 at 9:25 AM, Teresa Johnson 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. Passes internal te
Ok if large tests pass.
David
On Thu, Oct 16, 2014 at 9:16 AM, Teresa Johnson 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 was not available
>
- update_ssa (TODO_update_ssa);
>
>/* Local pure-const may imply need to fixup the cfg. */
> if (execute_fixup_cfg () & TODO_cleanup_cfg)
>
> Dehao
>
> On Wed, Oct 15, 2014 at 10:50 AM, Xinliang David Li
> wrote:
>> Is it destroyed by value pro
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 wrote:
> This patch recalculates dominance info before update_ssa call in
> AutoFDO. This fixes bug when dominance
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
wrote:
> The following patch fixes PR61889 for x86_64-w64-mingw32. Details can be found
> on https://gcc.gnu.org/bugzilla/show_bug
ok.
David
On Sun, Oct 12, 2014 at 2:59 PM, Teresa Johnson 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 it.
>
> For func_r
Ok (please also guard it with L_IPO_COMP_MODE).
David
On Tue, Oct 7, 2014 at 11:27 AM, Teresa Johnson 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 subsequent modules. Handle
On Mon, Oct 6, 2014 at 1:31 PM, Jan Hubicka 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 given
On Mon, Oct 6, 2014 at 11:22 AM, Jan Hubicka 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 the current
oops -- misread it :)
Ok.
David
On Fri, Oct 3, 2014 at 9:45 AM, Teresa Johnson wrote:
> 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
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 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_
This patch should be targeting trunk gcc?
David
On Fri, Oct 3, 2014 at 9:23 AM, Rong Xu 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, a deleted
On Wed, Oct 1, 2014 at 1:42 AM, Richard Earnshaw wrote:
> On 30/09/14 21:30, Eric Christopher wrote:
>> On Tue, Sep 30, 2014 at 5:57 AM, Marcus Shawcroft
>> wrote:
>>> On 22 September 2014 19:41, Carrot Wei wrote:
Hi
The extended register width in add/adds/sub/subs/cmp instruction
Probably need to file a bug to track the copyrename2 problem.
David
On Wed, Oct 1, 2014 at 9:59 AM, Teresa Johnson wrote:
> This patch removes some asserts my jump threading patch r215739 added.
> An upstream pass (copyrename2) is introducing some bogus profile
> counts, so we can't assert that
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?
>
See https://gcc.gnu.org/wiki/LightweightIpo It is a feature in google
GCC branches.
David
>> for the profiled
not sure if there is a better way, but ok.
David
On Wed, Sep 24, 2014 at 6:20 AM, Teresa Johnson 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 this by using target
ok.
David
On Tue, Sep 23, 2014 at 10:27 AM, Teresa Johnson 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 from existing funct
On Mon, Sep 22, 2014 at 8:04 AM, Teresa Johnson wrote:
> On Mon, Sep 22, 2014 at 1:36 AM, Nathan Sidwell 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
>>>> containi
On Mon, Sep 22, 2014 at 1:36 AM, Nathan Sidwell 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
>>
On Sun, Sep 21, 2014 at 5:48 AM, Nathan Sidwell 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 discarded whe
1.5M increase is not big concern. Ok with that.
David
On Tue, Sep 16, 2014 at 10:51 AM, Teresa Johnson wrote:
> On Tue, Sep 16, 2014 at 8:07 AM, Xinliang David Li wrote:
>> The zero_counts array is passed to gcov_build_callgraph but not used
>> until the dyn-cgraph is initial
ang David Li 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_nod
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 wrote:
> This patch addresses issues when running gcov-tool after performing
> COMDAT fixup during dyn
ok.
David
On Mon, Sep 15, 2014 at 1:43 PM, Sharad Singhai 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 targets which ac
ok.
David
On Thu, Sep 11, 2014 at 11:49 AM, Teresa Johnson wrote:
> 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:
>>>
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 reader code with the merger by defininig
>> some hooks for different callbacks?
>
> Do you
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 wrote:
> While porting recent support for a build info section in the gcda from
> google/4_8 to 4_9 and doing manual testing, I discover
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 wrote:
> On 09/09/14 19:45, Xinliang David Li wrote:
>> Richard, thanks for the review. The revised patch is attached. Is th
With gcc regression test, no regressions are found.
David
On Tue, Sep 9, 2014 at 11:45 AM, Xinliang David Li 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
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
PR target/63209
* config/arm/arm.md (movcond_addsi): Handle case where source
and target operands are the same
2014-09-08
===
--- ChangeLog (revision 215039)
+++ ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2014-09-08 Xinliang David Li
+
+ PR target/63209
+ * config/arm/arm.md (movcond_addsi_1): New pattern.
+ (movcond_addsi): Add a constraint.
+
2014-09-08 Trevor
ok. The patch is fine.
On Thu, Aug 28, 2014 at 1:46 PM, Teresa Johnson wrote:
> On Thu, Aug 28, 2014 at 1:40 PM, Xinliang David Li wrote:
>>
>> Do you know why the previous check is not enough ?
>>
>> cgraph_can_remove_if_no_direct_calls_and_refs_p (struct cgrap
e 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
> wrote:
>> Is it a problem specific to LIPO?
>>
>>
ok.
David
On Sat, Aug 23, 2014 at 11:42 AM, Teresa Johnson 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 Teresa Johnso
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 abstract origin node,
> leading
> to creating a new one after LIPO linking when we invoke similar handling in
> symtab_remove_unreachable_nodes, wh
n?
David
> instead of where it is
> inserted. This is also problematic.
>
> Wei.
>
> On Thu, Aug 7, 2014 at 12:11 PM, Xinliang David Li wrote:
>> Is this
>>
>> [1.cc : 179:64] Reader::~Reader (&version);
>>
>> from an inline instance?
>>
>>
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 wrote:
> We saw bb like this in the IR dump after pass_build_cfg:
>
> :
> [1.cc : 205:45] D.332088 = table->_vptr.Table;
> [1.cc : 205:45] D.332134 = D.332088 + 104;
looks good. thanks.
David
On Sat, Jul 26, 2014 at 12:08 AM, Nathan Sidwell 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 more chan
Ok. The internal benchmark testing also shows no change in behavior.
David
On Fri, Jul 25, 2014 at 2:55 PM, Jeff Law wrote:
> On 07/23/14 15:52, Xinliang David Li wrote:
>>
>> Index: ChangeLog
>> ===
>>
On Wed, Jul 23, 2014 at 11:45 PM, Nathan Sidwell 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
> follow exist
ternal id based on assembler name and source location. */
+DEFPARAM (PARAM_PROFILE_FUNC_INTERNAL_ID,
+ "profile-func-internal-id",
+ "use internal function id in profile lookup",
+ 0, 0, 1)
+
/* Avoid SLP vectorization of large basic bl
ok.
David
On Wed, Jul 23, 2014 at 1:46 PM, Teresa Johnson 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 internal test. Ok fo
; 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
> wrote:
>>
>> On Tue, Jul 22, 2014 at 8:14 PM, Jeff Law wrote:
>> > On 07/16/14 14:32
1 - 100 of 1034 matches
Mail list logo
