This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch ping


> >
> >
> >> estimate_num_insns is currently used for several things:
> >>
> >> -- on several places (loop unrolling, unswitching, exception
> >>    handling expansion), to estimate the size of the code
> >> -- in prefetching, to estimate time necessary to execute the
> >>    code
> >> -- in inlining for magic heuristic (that pretends to do the
> >>    former, but in fact turns out to be closer to the latter)
> >>
> >> Not surprisingly, it cannot work well enough for all these usages
> >> (in particular, the optimizations that rely on it being the size of
> >> the code suffer by the unrealistical values returned for calls and
> >> divisions).  This patch makes it possible to select which of these
> >> three estimates should be returned (by passing the structure containing
> >> costs of various constructs to it).
> One thing that I didn't like with this patch was exposing the extra
> parameter at all call sites like estimate_num_insns (cfun,
> &eni_inlining_weights).
> Can we at least have wrappers around that like
> estimate_num_insns_for_inlining (cfun) or whatever better we come up with?

the reason I decided to expose this parameter everywhere is that this
way, tree_num_loop_insns can also be parametrized on what metrics we do
want to use (without need to create three versions of this function).
I can create the wrappers if you prefer anyway, although I think it
would be a bit confusing.


> Otherwise splitting the cost metrics is the only sane way to go - it's 
> being on
> my todo for splitting optimize-size and optimize-speed counts for inlining 
> as
> well.
> I think I cannot approve this change though ;)
> Thanks,
> Richard.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]