Denis Chertykov schrieb:
>> Georg-Johann Lay schrieb:
>>> Denis Chertykov schrieb:
>>>
>>>> What difference in size of avr-libc ?
>>> I have no tool for smart size analysis, so here is just a diff:
>>>
>>> After rebuilding avr-libc with respective compiler version, did
>>> respectively:
>>>
>>> $ find . -name 'lib[mc].a' -exec avr-size {} ';' > size-orig.txt
>>> $ find . -name 'lib[mc].a' -exec avr-size {} ';' > size-patch.txt
>>>
>>> and then
>>>
>>> $ diff -U 0 size-orig.txt size-patch.txt > size.diff
>>>
>>> As far as I can see, there is not a big gain but no object increases in
>>> size.
>>>
>>> For some files like ./avr/lib/avr2/libc.a:dtoa_prf.o size gain is 3%.
>>> For ./avr/lib/avr4/libc.a:vfprintf_std.o it's 1.7% and for others just one
>>> instruction better.
>> Actually there are some cases where the size increases by one instruction:
>>
>>> - 464 0 0 464 1d0 realloc.o (ex
>>> ./avr/lib/avr31/libc.a)
>>> + 466 0 0 466 1d2 realloc.o (ex
>>> ./avr/lib/avr31/libc.a)
>>> - 464 0 0 464 1d0 realloc.o (ex
>>> ./avr/lib/avr3/libc.a)
>>> + 466 0 0 466 1d2 realloc.o (ex
>>> ./avr/lib/avr3/libc.a)
>> Will have a look tomorrow; presumably it's adding +/-1 that force a scratch
>> whilst the old code does not.
Is because different spill generation. Both cases do spilling (same frame size)
but a bit different. If there was a MOVW instruction the code would be smaller,
so I think it's a rare corner case.
> However results are good.
> The patch can be committed.
>
> Denis.
Applied with the proposed can_create_pseudo_p()
Johann
