From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.22]) by sourceware.org (Postfix) with ESMTPS id F4096384FE90 for ; Sat, 10 Dec 2022 12:15:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F4096384FE90 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gjlay.de Authentication-Results: sourceware.org; spf=none smtp.mailfrom=gjlay.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1670674503; s=strato-dkim-0002; d=gjlay.de; h=In-Reply-To:From:References:To:Subject:Date:Message-ID:Cc:Date:From: Subject:Sender; bh=azFeowNXuwaX6RHrFcuihIZluCifNDkusoF4DgOmXPU=; b=Disn1T0D5OLN4GO8S6bp35wx5QsLa65DM+hDjR8cFkTbSwb5XMz2izNWA9rHsEMM8E 9U8QFN4CrnF4WUXFiNZ5Q5IlV84xlgdfKDbq1iyBgKkkAFAUNqT2vUZGVhV1x5VBR+mR GB3Wv3qByhwmqG6m6W042OCz+f7ojUyaRstIm8VQVcRlYJZ2Z+NrlhRK9ZTbf53CU83q Q6jIKMY0BNOU8EKS1VuuZbWZOos+YD2BjgzC9F9hFQRF6gsGNtp4VdjS1nzNf8Gx3scL e/0n2m/DOTUQWCHvVt5mufWtT8djMiDCfMD3PgMzj1f7RFSOM5woO/Yucf92PZ5sKGJI Sk3g== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":LXoWVUeid/7A29J/hMvvT3koxZnKT7Qq0xotTetVnKkagtK/o3uhL+IIhZtSUNg=" X-RZG-CLASS-ID: mo00 Received: from [192.168.2.102] by smtp.strato.de (RZmta 48.2.1 DYNA|AUTH) with ESMTPSA id aba1dcyBACF30ii (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Sat, 10 Dec 2022 13:15:03 +0100 (CET) Message-ID: Date: Sat, 10 Dec 2022 13:15:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [IRA] Code bloat due to register spills in v9, v10, v11, v12 and master Content-Language: en-US To: Vladimir Makarov , gcc@gcc.gnu.org References: <91876f97-c1ba-2893-75c8-a765c0d9d37e@gjlay.de> From: Georg-Johann Lay In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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.