* [IRA] Code bloat due to register spills in v9, v10, v11, v12 and master
@ 2022-12-09 19:23 Georg-Johann Lay
2022-12-09 21:14 ` Vladimir Makarov
0 siblings, 1 reply; 4+ messages in thread
From: Georg-Johann Lay @ 2022-12-09 19:23 UTC (permalink / raw)
To: gcc; +Cc: Vladimir Makarov
There is the following code size regression, filed as
https://gcc.gnu.org/PR90706
Simple test cases are, for example
#define PORT (*((unsigned char volatile*) 0x24))
unsigned short var16;
void func (void)
{
if (2048000ul * var16 > 1200000ul)
PORT |= 1;
}
When I compile it with
$ avr-gcc -Os bloat1.c -c && avr-size bloat1.o
the code size increases from 36 bytes (v8) to 88 bytes (v13).
Apart from that, register pressure is much higher because a frame
pointer is set up for no reason, and the values go through stack slots
for no reason.
Even test cases which don't require any code like
long func2 (void)
{
long var32;
__asm ("; some code %0" : "=r" (var32));
return var32;
}
increase in register pressure (x2), stack usage (from 0 to 6 bytes) and
code size from 2 bytes (v8) to 34 bytes (v13).
Some projects like QMK "solved" the problem by declaring GCC > v8 to be
"incompatible" with their project, see
https://github.com/qmk/qmk_firmware/issues/6719
In own projects I observed the problem, too, and the only solution is to
use v8 or older. Options like -fcaller-saves or -fira-algorithm= have
no effect.
To configure, I used --target=avr --disable-nls --with-dwarf2
--enable-languages=c,c++ --with-gnu-as --with-gnu-ld --disable-shared,
so nothing special.
The problem is present in v9, v10, v11, v12 and master (future v13), so
sitting around for quite a while, so maybe it's not fixed because RA
maintainers are not aware of the problem.
Thanks for any help,
Johann
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [IRA] Code bloat due to register spills in v9, v10, v11, v12 and master
2022-12-09 19:23 [IRA] Code bloat due to register spills in v9, v10, v11, v12 and master Georg-Johann Lay
@ 2022-12-09 21:14 ` Vladimir Makarov
2022-12-10 12:15 ` Georg-Johann Lay
0 siblings, 1 reply; 4+ messages in thread
From: Vladimir Makarov @ 2022-12-09 21:14 UTC (permalink / raw)
To: Georg-Johann Lay, gcc
On 2022-12-09 14:23, Georg-Johann Lay wrote:
> There is the following code size regression, filed as
>
> https://gcc.gnu.org/PR90706
>
I am sorry, I feel your frustration. I was not aware of this PR.
Unfortunately, the PR was marked as P4 and I have too many open PRs and
should prioritize them.
I've just started to work on this issue. It is hard for me to say when
it will be fixed. I'll give an update on the next week.
> Simple test cases are, for example
>
> #define PORT (*((unsigned char volatile*) 0x24))
>
> unsigned short var16;
>
> void func (void)
> {
> if (2048000ul * var16 > 1200000ul)
> PORT |= 1;
> }
>
> When I compile it with
>
> $ avr-gcc -Os bloat1.c -c && avr-size bloat1.o
>
> the code size increases from 36 bytes (v8) to 88 bytes (v13).
>
> Apart from that, register pressure is much higher because a frame
> pointer is set up for no reason, and the values go through stack slots
> for no reason.
>
> Even test cases which don't require any code like
>
> long func2 (void)
> {
> long var32;
> __asm ("; some code %0" : "=r" (var32));
> return var32;
> }
>
> increase in register pressure (x2), stack usage (from 0 to 6 bytes)
> and code size from 2 bytes (v8) to 34 bytes (v13).
>
> Some projects like QMK "solved" the problem by declaring GCC > v8 to
> be "incompatible" with their project, see
> https://github.com/qmk/qmk_firmware/issues/6719
>
> In own projects I observed the problem, too, and the only solution is
> to use v8 or older. Options like -fcaller-saves or -fira-algorithm=
> have no effect.
>
> To configure, I used --target=avr --disable-nls --with-dwarf2
> --enable-languages=c,c++ --with-gnu-as --with-gnu-ld --disable-shared,
> so nothing special.
>
> The problem is present in v9, v10, v11, v12 and master (future v13),
> so sitting around for quite a while, so maybe it's not fixed because
> RA maintainers are not aware of the problem.
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [IRA] Code bloat due to register spills in v9, v10, v11, v12 and master
2022-12-09 21:14 ` Vladimir Makarov
@ 2022-12-10 12:15 ` Georg-Johann Lay
2022-12-10 14:10 ` Richard Biener
0 siblings, 1 reply; 4+ messages in thread
From: Georg-Johann Lay @ 2022-12-10 12:15 UTC (permalink / raw)
To: Vladimir Makarov, gcc
Am 09.12.22 um 22:14 schrieb Vladimir Makarov:
>
> On 2022-12-09 14:23, Georg-Johann Lay wrote:
>> There is the following code size regression, filed as
>>
>> https://gcc.gnu.org/PR90706
>>
>
> I am sorry, I feel your frustration. I was not aware of this PR.
> Unfortunately, the PR was marked as P4 and I have too many open PRs and
> should prioritize them.
>
> I've just started to work on this issue. It is hard for me to say when
> it will be fixed. I'll give an update on the next week.
Hi Vladimir,
Thank you so much.
As far as I understand, avr is a ternary target and hence PRs for avr
will have priority P4 or P5?
Johann
>> Simple test cases are, for example
>>
>> #define PORT (*((unsigned char volatile*) 0x24))
>>
>> unsigned short var16;
>>
>> void func (void)
>> {
>> if (2048000ul * var16 > 1200000ul)
>> PORT |= 1;
>> }
>>
>> When I compile it with
>>
>> $ avr-gcc -Os bloat1.c -c && avr-size bloat1.o
>>
>> the code size increases from 36 bytes (v8) to 88 bytes (v13).
>>
>> Apart from that, register pressure is much higher because a frame
>> pointer is set up for no reason, and the values go through stack slots
>> for no reason.
>>
>> Even test cases which don't require any code like
>>
>> long func2 (void)
>> {
>> long var32;
>> __asm ("; some code %0" : "=r" (var32));
>> return var32;
>> }
>>
>> increase in register pressure (x2), stack usage (from 0 to 6 bytes)
>> and code size from 2 bytes (v8) to 34 bytes (v13).
>>
>> Some projects like QMK "solved" the problem by declaring GCC > v8 to
>> be "incompatible" with their project, see
>> https://github.com/qmk/qmk_firmware/issues/6719
>>
>> In own projects I observed the problem, too, and the only solution is
>> to use v8 or older. Options like -fcaller-saves or -fira-algorithm=
>> have no effect.
>>
>> To configure, I used --target=avr --disable-nls --with-dwarf2
>> --enable-languages=c,c++ --with-gnu-as --with-gnu-ld --disable-shared,
>> so nothing special.
>>
>> The problem is present in v9, v10, v11, v12 and master (future v13),
>> so sitting around for quite a while, so maybe it's not fixed because
>> RA maintainers are not aware of the problem.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [IRA] Code bloat due to register spills in v9, v10, v11, v12 and master
2022-12-10 12:15 ` Georg-Johann Lay
@ 2022-12-10 14:10 ` Richard Biener
0 siblings, 0 replies; 4+ messages in thread
From: Richard Biener @ 2022-12-10 14:10 UTC (permalink / raw)
To: Georg-Johann Lay; +Cc: Vladimir Makarov, gcc
> Am 10.12.2022 um 13:15 schrieb Georg-Johann Lay <avr@gjlay.de>:
>
>
>
>> Am 09.12.22 um 22:14 schrieb Vladimir Makarov:
>>> On 2022-12-09 14:23, Georg-Johann Lay wrote:
>>> There is the following code size regression, filed as
>>>
>>> https://gcc.gnu.org/PR90706
>>>
>> I am sorry, I feel your frustration. I was not aware of this PR. Unfortunately, the PR was marked as P4 and I have too many open PRs and should prioritize them.
>> I've just started to work on this issue. It is hard for me to say when it will be fixed. I'll give an update on the next week.
>
> Hi Vladimir,
>
> Thank you so much.
>
> As far as I understand, avr is a ternary target and hence PRs for avr will have priority P4 or P5?
Yes, since AVR is not primary or secondary regressions specific to AVR are P4 or lower.
If the same issue can be observed on a target that is secondary or primary that would change this aspect.
Richard
> Johann
>
>
>>> Simple test cases are, for example
>>>
>>> #define PORT (*((unsigned char volatile*) 0x24))
>>>
>>> unsigned short var16;
>>>
>>> void func (void)
>>> {
>>> if (2048000ul * var16 > 1200000ul)
>>> PORT |= 1;
>>> }
>>>
>>> When I compile it with
>>>
>>> $ avr-gcc -Os bloat1.c -c && avr-size bloat1.o
>>>
>>> the code size increases from 36 bytes (v8) to 88 bytes (v13).
>>>
>>> Apart from that, register pressure is much higher because a frame pointer is set up for no reason, and the values go through stack slots for no reason.
>>>
>>> Even test cases which don't require any code like
>>>
>>> long func2 (void)
>>> {
>>> long var32;
>>> __asm ("; some code %0" : "=r" (var32));
>>> return var32;
>>> }
>>>
>>> increase in register pressure (x2), stack usage (from 0 to 6 bytes) and code size from 2 bytes (v8) to 34 bytes (v13).
>>>
>>> Some projects like QMK "solved" the problem by declaring GCC > v8 to be "incompatible" with their project, see
>>> https://github.com/qmk/qmk_firmware/issues/6719
>>>
>>> In own projects I observed the problem, too, and the only solution is to use v8 or older. Options like -fcaller-saves or -fira-algorithm= have no effect.
>>>
>>> To configure, I used --target=avr --disable-nls --with-dwarf2 --enable-languages=c,c++ --with-gnu-as --with-gnu-ld --disable-shared, so nothing special.
>>>
>>> The problem is present in v9, v10, v11, v12 and master (future v13), so sitting around for quite a while, so maybe it's not fixed because RA maintainers are not aware of the problem.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-12-10 15:38 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-09 19:23 [IRA] Code bloat due to register spills in v9, v10, v11, v12 and master Georg-Johann Lay
2022-12-09 21:14 ` Vladimir Makarov
2022-12-10 12:15 ` Georg-Johann Lay
2022-12-10 14:10 ` Richard Biener
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).