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.
