2011/9/25 Jan Hubicka <hubi...@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
>> >
>> >
>> >
>
