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

Pranav Bhandarkar pranav.bhandarkar@gmail.com
Thu Sep 20 21:59:00 GMT 2007

> 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.

> 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.

If the above are ok, I will submit a revised patch with appropriate
changes to the target hook ( for e.g remove the word inline as
estimate_num_insns_1 isnt used only for inlining ) .

Please do let me know.


More information about the Gcc-patches mailing list