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 +592,9 @@ account_size_time (struct inline_summary
>> }
>> else
>> {
>> + e->predicate = or_predicates (summary->conds, &e->predicate, pred);
>> e->size += size;
>> e->time += time;
>> if (e->time > MAX_TIME * INLINE_TIME_SCALE)
>
> As we discussed, this is not needed in current form because we arrange first
> predicate to be always
> true and thus we could always place there all the costs that did not fit
> elwhere.
>
> The patch has a problem with fact that the predicates must be always
> conservative i.e. when
> they are proved to be false the code must be unreachable after inlining.
I don't understand your point. The OR-ing of the predicates allows us to merge
size_time_entries and keep the total number of them under a desired limit.
Currently all merging goes into entry[0], and the patch makes the extra
information to get distributed across more entries. Because we OR the
predicates, we keep the information conservative; now in order to say that
certain code will be unreachable the inliner has to prove to be false the OR-ed
predicate.
Now, one can argue whether it is actually a benefit to distribute the
information more evenly and, consequently, making more predicates harder to
disprove. In current scheme we have the surplus of size_time information under
one impossible-to-disprove predicate and many entries with
easier-to-disprove-predicates. My patch changes the situation to having most
of the size_time information in entries with harder-but-possible-to-disprove
predicates.
Am I missing something?
>
> We could either go with your patch with the distance fuction modified to
> accept
> only predicates such that the new predicate is implied by them. If you are
> willing to play with this, I have no problem with going for this.
Yes, favoring predicates that already imply the new one is a good suggestion.
Thank you,
--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics
