Re: in-accurate costs to estimate function body size?

[Richard Biener <rguenther at suse dot de>]

On Fri, 28 Oct 2016, Pitchumani Sivanupandi wrote:

> GCC inlines small functions if the code size after expansion is not exceeded.
> For attached test case (inline.c) code size become higher if 'func1' is
> inlined. It happens because the CONVERT_EXPR/ NOP_EXPR are considered as zero
> size expression.
> 
> Function 'func1' is auto-inlined with -Os option (gcc -Os -S inline.c).
> Code size is better if 'func1' is not inlined.
>   gcc -Os -S inline.c -DDONTINLINE
> 
> Ref: gcc/tree-inline.c (estimate_operator_cost)
> Not all convert expressions are 'free' in terms of size. At least for targets
> like AVR, it requires few instructions to be generated as the register size
> is just 1 byte.
> 
> Is it Ok to associate any cost to CONVERSION expressions?
> Also there is comment '??? We may consider mapping RTL costs to this'.
> 
> Or any other way to get the code size estimation correct?

Estimating code size from GIMPLE is hard thus we apply heuristics.
Generally conversions tend to be free compared to the rest but sure,
improvements are always possible.  For targets like AVR its probably
more important to consider what we do for memory ops -- the width
of the operation.  That is, operation cost should be scaled by
the number of registers involved (thus consider > word_mode modes
or not natively supported vector types, etc).

There is a lot of room for improvement but as this is a heuristic
the effect on non-micro-benchmarks is usually a garbage-in - garbage-out
kind, sth helping a micro-benchmark may hit real world cases.

Richard.