in-accurate costs to estimate function body size?

[Pitchumani Sivanupandi <pitchumani.sivanupandi@xxxxxxxxxxxxx>]

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?

Regards,
Pitchumani

typedef int int8_t __attribute__((__mode__(__QI__)));
typedef int int16_t __attribute__((__mode__(__HI__)));
typedef unsigned int uint16_t __attribute__((__mode__(__HI__)));
typedef int int32_t __attribute__((__mode__(__SI__)));
typedef unsigned int uint32_t __attribute__((__mode__(__SI__)));

int32_t i32var1, i32var2;
int16_t i16var1;
int8_t i8var1, i8var2, i8var3;
#if DONTINLINE
static uint32_t __attribute__((noinline))
#else
static uint32_t
#endif
func1 (void)
{
  i32var1 = (uint16_t)i8var1 + (uint32_t)i8var2 +
    (uint32_t)(i8var1) + (uint16_t)(i8var2);
  return i32var1;
}

void __attribute__((noinline))
func2 ()
{
  i16var1 = func1();
}

int
main ()
{
  func2();
  return func1();
}