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

[Richard Guenther <richard dot guenther at gmail dot com>]

2011/9/25 Jan Hubicka <hubicka@ucw.cz>:
>>
>> 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 detecting optimized out callgraph edges).
>
>> of the size/time values if using or_predicates?
>
> Maximum should work if the predicates are known to be disjoint. Otherwise I guess
> sum is the only conservative way.
>>
>> 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.
>>
>> > ? ? ? 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.
>
> Entry[0] is always true predicate BTW. ?This is why you don't need or predicate there.
> This is arranged in:
>
> ?/* When we run into maximal number of entries, we assign everything to the
> ? ? constant truth case. ?Be sure to have it in list. */
> ?bb_predicate = true_predicate ();
> ?account_size_time (info, 0, 0, &bb_predicate);
>
> It is there precisely to make the predicates overflow to work. ?It is quite
> stupid way to handle too many predicates, but I tought I don't need to worry at
> least in the initial implementation.
>
> I will take at the patch later today.
>>
>> 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.
>
> Again the predicates must be mutually disjoint for that. ?I.e. when we have
>
> if (op0 > 10)
> ?some code
> if (op1 > 10)
> ?the same code
>
> You will account same size and time at predicate (op0 > 10) and (op1 > 10) and they
> are additive when values of op0 and op1 are not disjoint.

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?

> Honza
>>
>> Richard.
>>
>> > OK for trunk assuming testing on x86_64-linux-gnu shows no regressions?
>> >
>> > Thank you,
>> >
>> > --
>> > Maxim Kuvyrkov
>> > CodeSourcery / Mentor Graphics
>> >
>> >
>> >
>