Bug 91189 - 20% binary size regression in avr-gcc 9.1.0 from 8.3.0
Summary: 20% binary size regression in avr-gcc 9.1.0 from 8.3.0
Status: RESOLVED DUPLICATE of bug 90706
Alias: None
Product: gcc
Classification: Unclassified
Component: other (show other bugs)
Version: 9.1.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: missed-optimization
Depends on:
Blocks:
 
Reported: 2019-07-17 16:27 UTC by Lars Christensen
Modified: 2019-12-13 20:55 UTC (History)
0 users

See Also:
Host:
Target: avr
Build:
Known to work:
Known to fail:
Last reconfirmed: 2019-10-14 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lars Christensen 2019-07-17 16:27:00 UTC
There seem to be a severe ~20% code size regression on AVR target (atmega328p) in gcc 9.1.0.

I'm building https://github.com/gnea/grbl, which need to fit in 32k. This used to work just fine (29786 bytes), but with 9.1.0 it is way over target size (35492 bytes).

Compile options are the default '-Os -flto' on both.

gcc 8.3.0

% avr-gcc --version
avr-gcc (GCC) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

% avr-size grbl.hex                                                                                                                                                                          
   text    data     bss     dec     hex filename
      0   29786       0   29786    745a grbl.hex

gcc 9.1.0:

% avr-gcc --version

avr-gcc (GCC) 9.1.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

% avr-size grbl.hex
   text    data     bss     dec     hex filename
      0   35492       0   35492    8aa4 grbl.hex
Comment 1 Zygmunt 2019-07-24 21:56:27 UTC
I can confirm a problem with gcc 9.1.0.

I hit into it today when I tried compile DFU bootloder from LUFA project for atmega32u4.
From some unknwon reason for me it compiles without any problem for atmega16u2.

Compiling DFU bootloader for atmega32u4 and atmega16u2 works on gcc-8.3.0.
Comment 2 Georg-Johann Lay 2019-07-31 23:18:50 UTC
How did you conclude it's a target issue? Would you pinpoint where in the avr backend the problem is?
Comment 3 Nicola Fontana 2019-09-25 08:32:50 UTC
This is still an issue with gcc-9.2.0.
Comment 4 Georg-Johann Lay 2019-10-14 13:57:28 UTC
(In reply to Nicola Fontana from comment #3)
> This is still an issue with gcc-9.2.0.

We still have no test case.
Comment 5 Witold Markowski 2019-12-13 15:48:45 UTC
I did a small research in this topic and now I know that avr-gcc-9.1.0 compiler generates some additional, overhead operations, like:


     932:	6e 87       	std	Y+14, r22	; 0x0e
     934:	7f 87       	std	Y+15, r23	; 0x0f
     936:	88 8b       	std	Y+16, r24	; 0x10
     938:	99 8b       	std	Y+17, r25	; 0x11
     93a:	6e 85       	ldd	r22, Y+14	; 0x0e
     93c:	7f 85       	ldd	r23, Y+15	; 0x0f
     93e:	88 89       	ldd	r24, Y+16	; 0x10
     940:	99 89       	ldd	r25, Y+17	; 0x11 

Storing and reading back the same registers.

I just found that exactly the same case is already reported with issue id 90706. Because of this I will not attach any examples here. In my opinion the current issue depends on 90706 (please somebody update the 'Depends on' field of the issue).
When 90706 is fixed then we should recheck this again and we will se how much it improves the situation.
Comment 6 Georg-Johann Lay 2019-12-13 20:55:10 UTC

*** This bug has been marked as a duplicate of bug 90706 ***