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