Re: [PATCH] Cost of inlining when the function has call to a target-specific builtin

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

On 9/16/07, Pranav Bhandarkar <pranav.bhandarkar@gmail.com> wrote:
> > This doesn't fit with the modularized cost metrics we have.  That is,
> > estimate_num_insns_1 is not only used for inlining.
>
> The comments for estimate_num_insns_1 say
> /* Used by estimate_num_insns.  Estimate number of instructions seen
>    by given statement.  */
>
> From this my understanding is that even If esimate_num_insns_1 is not
> used only for inlining, wouldnt it be better to get, from the backend,
>  a more accurate count of the number of instructions seen by a call to
> a target_specific builtin ?
>
> If estimate_num_insns_1 isnt used only for inlining maybe the name of
> the hook should change ?

Possibly.  There are weights for size, time and for inlining (we should
drop the latter in favor of using either size or time weights dependent
on inlining goal).  So the target hook should take an extra parameter
to select the mode used.  Though this requires re-organizing code too
much for stage3.

Can you investigate whether there are target builtins that have a
non-negligible call cost?  I guess simply treating all target builtins
the same as BUILT_IN_PREFETCH should work.

Richard.