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

Richard Guenther richard.guenther@gmail.com
Sun Sep 16 21:46:00 GMT 2007

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.


More information about the Gcc-patches mailing list