On Tue, Nov 8, 2011 at 7:34 AM, Maxim Kuvyrkov wrote:
> On 2/11/2011, at 10:18 AM, Richard Guenther wrote:
>>
> Thus, I don't think we want to
> merge this in its current form or in this stage1.
What is the benefit of pushing this to a later release? If anything,
merging t
On 2/11/2011, at 10:18 AM, Richard Guenther wrote:
>
Thus, I don't think we want to
merge this in its current form or in this stage1.
>>>
>>> What is the benefit of pushing this to a later release? If anything,
>>> merging the support for iterative optimizations now will allow us to
>
On Sat, Oct 29, 2011 at 1:06 AM, Matt wrote:
> On Sat, 29 Oct 2011, Maxim Kuvyrkov wrote:
>
>>> I like this variant a lot better than the last one - still it lacks any
>>> analysis-based justification for iteration (see my reply to Matt on
>>> what I discussed with Honza).
>>
>> Yes, having a way
Hi,
On Fri, Oct 28, 2011 at 04:06:20PM -0700, Matt wrote:
>
...
>
> I agree (of course). Having the knob will be very useful for testing
> and determining the acceptance criteria for the later "smartness".
> While terminating early would be a nice optimization, the feature is
> still intrinsical
On Sat, 29 Oct 2011, Maxim Kuvyrkov wrote:
I like this variant a lot better than the last one - still it lacks any
analysis-based justification for iteration (see my reply to Matt on
what I discussed with Honza).
Yes, having a way to tell whether a function have significantly changed
would be
On 28/10/2011, at 11:43 PM, Richard Guenther wrote:
> On Fri, Oct 28, 2011 at 1:05 AM, Maxim Kuvyrkov
> wrote:
>>
>> OK for trunk?
>
> diff --git a/gcc/cgraph.c b/gcc/cgraph.c
> index f056d3d..4738b28 100644
> --- a/gcc/cgraph.c
> +++ b/gcc/cgraph.c
> @@ -2416,7 +2416,7 @@ cgraph_add_new_funct
On Fri, 28 Oct 2011, Richard Guenther wrote:
I discussed the idea of iterating early optimizations shortly with Honza.
I was trying to step back a bit and look at what we try to do right now,
which is, optimize functions in topological order (thus, try to make sure
all callees are already early
On Fri, Oct 28, 2011 at 1:05 AM, Maxim Kuvyrkov wrote:
> Richard,
>
> Just as Matt posted his findings about the effect of iterating early
> optimizations, I've got the new patch ready. This patch is essentially a
> complete rewrite and addresses the comments you made.
>
> On 18/10/2011, at 9:5
On Thu, Oct 27, 2011 at 11:53 PM, Matt wrote:
Then you'd have to analyze the compile-time impact of the IPA
splitting on its own when not iterating. ?Then you should look
at what actually was the optimizations that were performed
that lead to the improvement (I can see some ind
Richard,
Just as Matt posted his findings about the effect of iterating early
optimizations, I've got the new patch ready. This patch is essentially a
complete rewrite and addresses the comments you made.
On 18/10/2011, at 9:56 PM, Richard Guenther wrote:
>>>
>>> If we'd want to iterate earl
Then you'd have to analyze the compile-time impact of the IPA
splitting on its own when not iterating. ?Then you should look
at what actually was the optimizations that were performed
that lead to the improvement (I can see some indirect inlining
happening, but everything else would be a bug in pr
On Tue, Oct 18, 2011 at 1:45 AM, Maxim Kuvyrkov wrote:
> On 13/10/2011, at 12:58 AM, Richard Guenther wrote:
>
>> On Wed, Oct 12, 2011 at 8:50 AM, Maxim Kuvyrkov
>> wrote:
>>> The following patch adds new knob to make GCC perform several iterations of
>>> early optimizations and inlining.
>>>
>
On 13/10/2011, at 12:58 AM, Richard Guenther wrote:
> On Wed, Oct 12, 2011 at 8:50 AM, Maxim Kuvyrkov
> wrote:
>> The following patch adds new knob to make GCC perform several iterations of
>> early optimizations and inlining.
>>
>> This is for dont-care-about-compile-time-optimize-all-you-can
On Wed, Oct 12, 2011 at 8:50 AM, Maxim Kuvyrkov wrote:
> The following patch adds new knob to make GCC perform several iterations of
> early optimizations and inlining.
>
> This is for dont-care-about-compile-time-optimize-all-you-can scenarios.
> Performing several iterations of optimizations
14 matches
Mail list logo
