Re: [PATCH] Distribute inliner's size_time data across entries with similar predicates

2011-11-21 Thread Maxim Kuvyrkov
On 28/10/2011, at 7:24 PM, Maxim Kuvyrkov wrote: > On 20/10/2011, at 10:32 PM, Jan Hubicka wrote: > >> Hi, >>> Jan, >>> >>> The following patch started as a one-liner for ipa-inline-analysis.c: >>> account_size_time() to merge predicates when we are adding data to entry[0] >>> (i.e., when spac

Re: [PATCH] Distribute inliner's size_time data across entries with similar predicates

2011-10-27 Thread Maxim Kuvyrkov
On 20/10/2011, at 10:32 PM, Jan Hubicka wrote: > Hi, >> Jan, >> >> The following patch started as a one-liner for ipa-inline-analysis.c: >> account_size_time() to merge predicates when we are adding data to entry[0] >> (i.e., when space for 32 size_time entries is exhausted): >> >> @@ -537,6 +

Re: [PATCH] Distribute inliner's size_time data across entries with similar predicates

2011-10-20 Thread Jan Hubicka
Hi, > Jan, > > The following patch started as a one-liner for ipa-inline-analysis.c: > account_size_time() to merge predicates when we are adding data to entry[0] > (i.e., when space for 32 size_time entries is exhausted): > > @@ -537,6 +592,9 @@ account_size_time (struct inline_summary >

Re: [PATCH] Distribute inliner's size_time data across entries with similar predicates

2011-09-29 Thread Maxim Kuvyrkov
On 25/09/2011, at 11:21 PM, Jan Hubicka wrote: >> >> I wonder why we bother to record so many predicates though. > > Yep, I wonder if it comes from some real testcase? I didn't see functions > that > reach the limit and still be inlinable very often in practice. This patch wasn't inspired by

Re: [PATCH] Distribute inliner's size_time data across entries with similar predicates

2011-09-25 Thread Jan Hubicka
> > Hm, what do we do for > > if (op0 > 10) >if (op1 > 10) > some code > > ? Do we make sure to only register one predicate with op0 > 10 && op1 > 10? Yes, we end up with predicate (op0 > 10) && (op1 > 10). That is until we hit of maximum limit of clauses in a single predicate. Then

Re: [PATCH] Distribute inliner's size_time data across entries with similar predicates

2011-09-25 Thread Richard Guenther
2011/9/25 Jan Hubicka : >> >> Shouldn't this be either and_predicates or not accumulating but taking >> the minimum (or maximum?) > > The predicates are always assumed to be conservative estimate (i.e. when they > are false, the code is known to be unreachable. When they are true they may or > may

Re: [PATCH] Distribute inliner's size_time data across entries with similar predicates

2011-09-25 Thread Jan Hubicka
> > Shouldn't this be either and_predicates or not accumulating but taking > the minimum (or maximum?) The predicates are always assumed to be conservative estimate (i.e. when they are false, the code is known to be unreachable. When they are true they may or may not be. This is used when detect

Re: [PATCH] Distribute inliner's size_time data across entries with similar predicates

2011-09-24 Thread Richard Guenther
On Mon, Sep 19, 2011 at 10:16 PM, Maxim Kuvyrkov wrote: > Jan, > > The following patch started as a one-liner for ipa-inline-analysis.c: > account_size_time() to merge predicates when we are adding data to entry[0] > (i.e., when space for 32 size_time entries is exhausted): > > @@ -537,6 +592,9

[PATCH] Distribute inliner's size_time data across entries with similar predicates

2011-09-19 Thread Maxim Kuvyrkov
Jan, The following patch started as a one-liner for ipa-inline-analysis.c: account_size_time() to merge predicates when we are adding data to entry[0] (i.e., when space for 32 size_time entries is exhausted): @@ -537,6 +592,9 @@ account_size_time (struct inline_summary } else { +