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 used on google branches. We do
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
On 09/22/14 08:04, Teresa Johnson wrote:
The approach we now take for LIPO builds is to propagate the counts
LIPO?
for the profiled copy of the COMDAT to other modules. (Additionally
the indirect call profiling we perform in LIPO mode would point to a
module that we didn't have access to, w
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
containing the live version of the function. I cou
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
>>> to
>>> work though -- it involves emi
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
>>> to
>>> work though -- it involves emi
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 emitting a function's gcov_fn_info decl in the
same comdat group as the func
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
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 when being read in
by gcov-tool before recalculating module groups and
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 initialized. We should a
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 initialized. We should avoid increasing
> runtime memory overhead by not creating it if possible.
We could delay creation a little bit, until
The zero_counts array is passed to gcov_build_callgraph but not used
until the dyn-cgraph is initialized. We should avoid increasing
runtime memory overhead by not creating it if possible.
David
On Tue, Sep 16, 2014 at 7:57 AM, Teresa Johnson wrote:
> On Mon, Sep 15, 2014 at 9:29 PM, Xinliang D
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
> 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_
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
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 when being read in
by gcov-tool before recalculating module groups and summary info.
While here, cleaned up the g
15 matches
Mail list logo
