Finally had some time to pick this up again. See responses and
questions below. But it looks like you are commenting on a stale
version of the patch. See the update I sent in March:
https://gcc.gnu.org/ml/gcc-patches/2014-03/msg01176.html
On Sun, May 25, 2014 at 10:43 PM, Jan Hubicka wrote:
>>
> This patch attempts to address the lost profile issue for COMDATs in
> more circumstances, exposed by function splitting.
>
> My earlier patch handled the case where the comdat had 0 counts since
> the linker kept the copy in a different module. In that case we
> prevent the guessed frequencies
On Fri, Feb 28, 2014 at 9:13 AM, Teresa Johnson wrote:
Here's the new patch. The only changes from the earlier patch are in
handle_missing_profiles, where we now get the counts off of the entry
and call stmt bbs, and in tree_profiling, where we call
handle_missing_profiles earl
>>> Here's the new patch. The only changes from the earlier patch are in
>>> handle_missing_profiles, where we now get the counts off of the entry
>>> and call stmt bbs, and in tree_profiling, where we call
>>> handle_missing_profiles earlier and I have removed the outlined cgraph
>>> rebuilding co
On Thu, Feb 13, 2014 at 9:48 AM, Mike Stump wrote:
> On Feb 13, 2014, at 8:41 AM, Teresa Johnson wrote:
>> On Wed, Feb 12, 2014 at 2:03 PM, Xinliang David Li
>> wrote:
>
> [ extra lines deleted ]
>
>>> Should non comdat function be skipped?
>>
>> We warn in drop_profile if this is not a COMDAT,
On Feb 13, 2014, at 8:41 AM, Teresa Johnson wrote:
> On Wed, Feb 12, 2014 at 2:03 PM, Xinliang David Li wrote:
[ extra lines deleted ]
>> Should non comdat function be skipped?
>
> We warn in drop_profile if this is not a COMDAT, as we should only
> have this case and reach the call in that ca
On Wed, Feb 12, 2014 at 8:02 AM, Teresa Johnson wrote:
> On Wed, Feb 12, 2014 at 6:45 AM, Teresa Johnson wrote:
>> On Tue, Feb 11, 2014 at 6:13 PM, Xinliang David Li
>> wrote:
>>> On Tue, Feb 11, 2014 at 5:36 PM, Teresa Johnson
>>> wrote:
On Tue, Feb 11, 2014 at 5:16 PM, Xinliang David L
On Wed, Feb 12, 2014 at 6:45 AM, Teresa Johnson wrote:
> On Tue, Feb 11, 2014 at 6:13 PM, Xinliang David Li wrote:
>> On Tue, Feb 11, 2014 at 5:36 PM, Teresa Johnson wrote:
>>> On Tue, Feb 11, 2014 at 5:16 PM, Xinliang David Li
>>> wrote:
Why is call graph needed to determine whether to d
On Tue, Feb 11, 2014 at 6:13 PM, Xinliang David Li wrote:
> On Tue, Feb 11, 2014 at 5:36 PM, Teresa Johnson wrote:
>> On Tue, Feb 11, 2014 at 5:16 PM, Xinliang David Li
>> wrote:
>>> Why is call graph needed to determine whether to drop the profile?
>>
>> Because we detect this situation by loo
On Tue, Feb 11, 2014 at 5:36 PM, Teresa Johnson wrote:
> On Tue, Feb 11, 2014 at 5:16 PM, Xinliang David Li wrote:
>> Why is call graph needed to determine whether to drop the profile?
>
> Because we detect this situation by looking for cases where the call
> edge counts greatly exceed the callee
On Tue, Feb 11, 2014 at 5:16 PM, Xinliang David Li wrote:
> Why is call graph needed to determine whether to drop the profile?
Because we detect this situation by looking for cases where the call
edge counts greatly exceed the callee node count.
>
> If that is needed, it might be possible to lev
Why is call graph needed to determine whether to drop the profile?
If that is needed, it might be possible to leverage the ipa_profile
pass as it will walk through all function nodes to do profile
annotation. With this you can make decision to drop callee profile in
caller's context.
David
On Tu
On Tue, Feb 11, 2014 at 2:56 PM, Xinliang David Li wrote:
> Is it better to add some logic in counts_to_freq to determine if the
> profile count needs to be dropped completely to force profile
> estimation?
This is the problem I was mentioning below where we call
counts_to_freqs before we have th
Is it better to add some logic in counts_to_freq to determine if the
profile count needs to be dropped completely to force profile
estimation?
David
On Mon, Feb 10, 2014 at 2:12 PM, Teresa Johnson wrote:
> This patch attempts to address the lost profile issue for COMDATs in
> more circumstances,
This patch attempts to address the lost profile issue for COMDATs in
more circumstances, exposed by function splitting.
My earlier patch handled the case where the comdat had 0 counts since
the linker kept the copy in a different module. In that case we
prevent the guessed frequencies on 0-count f
15 matches
Mail list logo