On Mon, Sep 19, 2011 at 10:16 PM, Maxim Kuvyrkov <ma...@codesourcery.com> 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 @@ account_size_time (struct inline_summary
> }
> else
> {
> + e->predicate = or_predicates (summary->conds, &e->predicate, pred);
> e->size += size;
> e->time += time;
Shouldn't this be either and_predicates or not accumulating but taking
the minimum (or maximum?)
of the size/time values if using or_predicates?
I wonder why we bother to record so many predicates though.
> if (e->time > MAX_TIME * INLINE_TIME_SCALE)
>
> The rationale was that since we are accounting size and time under the entry
> we also need to make entry's predicate a superset of the predicate we want to
> account the data under.
>
> Then I thought that mushing all predicates into the single predicate of
> entry[0] will cause it to become true_predicate() very quickly, so I added
> logic to distribute incoming size_time information across all 32 entries by
> searching for entries with similar predicates.
That sounds expensive (without looking at the patch). Shouldn't we
instead look for similar size/time values (maybe sorting the
predicates)?
Thus, when size and time are equal we can simply or the predicates.
Richard.
> OK for trunk assuming testing on x86_64-linux-gnu shows no regressions?
>
> Thank you,
>
> --
> Maxim Kuvyrkov
> CodeSourcery / Mentor Graphics
>
>
>
