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

[Richard Guenther]

On 9/20/07, Pranav Bhandarkar <pranav.bhandarkar@gmail.com> wrote:
> > I don't think there should be a difference in the context of the cost
> > in this case.  the target builtins will have the same cost if we are
> > dealing with inlining costs or duplicating costs.  It should be the
> > number of instructions it will expand to (or close to that).
>
> Yes, even I am of the same opinion. I do think that the context of the
> cost in this case the mode.

Well, we have at least size and speed cost -- after all, if we could treat
everything the same for the two cases there would be no need for
the two cases ;)

> > 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.
>
> I did a quick scan through a few backends and didnt find non-negigible
> call cost target specific builtins. Therefore we might get away with
> treating it like BUILT_IN_PREFETCH. However, IMHO I dont think that
> should be the way to go,  because maybe in the future If there is a
> non-negligible target-specific builtin then treating it like
> BUILT_IN_PREFETCH (i.e. with a default cost of 1, in effect treating
> it as inexpensive ) will not scale well.

I think it is good enough for now given your quick scan.  That is,
I'd propose to add a new weight in the eni_weights structure for
target builtins and use that. Given that your patch doesn't introduce
sophisticated use of the target hook in any target and we're in stage3
already.

Thanks,
Richard.