From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) by sourceware.org (Postfix) with ESMTPS id 168C738500B1 for ; Sat, 10 Dec 2022 15:38:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 168C738500B1 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x52a.google.com with SMTP id i15so7006134edf.2 for ; Sat, 10 Dec 2022 07:38:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=k628z9hYD8iZOfYk3C0vp9dVDgE/nsZcuvMMYjKunzY=; b=GN6Kt/SY7nAL2TPdAC9xFduKhPQSlcUTd9DAzquSfRhor2Ww7878a8T+w8L4SkIpw8 pbg3V7FLjYtGM9CfX9K7y0oUCekdwIpBByXjUn3ZWFE3sS6wFLyAT9De0EF1oCIrE+IQ OHZ4Zph0j+7chRvK30UVMv91aMAhf6sAemlMHTNjO8NBcDN+3/GseJ5FI/XgW0EYNd9O 9js2I+HTyAoywdr66oxXmQoC1OpWbyOAcrcoFFjkgHDDI3kIWjbw/MYQVWuyMSneDVOt /V/gCKJNWtouYOcFdU5uE2GiH5paGcewas1VFzIS8nPG9grU4tZS/rYCAkF+D5EoS2BO nIVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=k628z9hYD8iZOfYk3C0vp9dVDgE/nsZcuvMMYjKunzY=; b=iFkB23xDWU+zC/Ram1fzEJQjWcjqFL/+I1pNpyCR0EOv1pky/lJuljxF5pz7Hs1KZK 5ywlYuv5MyNnVM/C0klueph/oh3WIAzo4wsW9zKxz4Q7Teff31VOczi1gz5dB/HfkMUN Wuzw+osadVPxd6EJJvTKl0ZwiTPx45PNAE2WKB7shBGp27R2HvMaI+dtUcdy9B2CkP0a QLfhN7DzLZt/zg0PUYKtcTtzAPJ66HWJFUnR9godlVjayuKybDGvT2e1J1Rpz1v9LP+S r0T2/3/Rqz6S3Jy5OoUG1JJqt1VQE2GZJM244D+BJzHIWLDlT/gwmIr952U5hWJ5ZQWV Zo2A== X-Gm-Message-State: ANoB5pmPzyJZQ1PQyA34JmAARFkr1HsoJ+EUgRGTuUe9/Q0SnkjNcE64 Iv9s9hKYdRhTgrPJfuDze03tjTlPgNA= X-Google-Smtp-Source: AA0mqf7Ado4u/wQiflvCCwBoS5Uqv6yMOwKy6MSW3UUzZCp45ge1i2xdQK6XLE7fHGMzK/P37KN4VQ== X-Received: by 2002:a17:907:7fa0:b0:7ad:9629:a63 with SMTP id qk32-20020a1709077fa000b007ad96290a63mr10523079ejc.25.1670681442675; Sat, 10 Dec 2022 06:10:42 -0800 (PST) Received: from smtpclient.apple (dynamic-095-118-111-027.95.118.pool.telefonica.de. [95.118.111.27]) by smtp.gmail.com with ESMTPSA id t15-20020a1709067c0f00b007aec1b39478sm1019895ejo.188.2022.12.10.06.10.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 10 Dec 2022 06:10:41 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Richard Biener Mime-Version: 1.0 (1.0) Subject: Re: [IRA] Code bloat due to register spills in v9, v10, v11, v12 and master Date: Sat, 10 Dec 2022 15:10:31 +0100 Message-Id: References: Cc: Vladimir Makarov , gcc@gcc.gnu.org In-Reply-To: To: Georg-Johann Lay X-Mailer: iPhone Mail (20B110) X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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 10.12.2022 um 13:15 schrieb Georg-Johann Lay : >=20 > =EF=BB=BF >=20 >> 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 >>>=20 >>> https://gcc.gnu.org/PR90706 >>>=20 >> I am sorry, I feel your frustration. I was not aware of this PR. Unfortun= ately, the PR was marked as P4 and I have too many open PRs and should prior= itize them. >> I've just started to work on this issue. It is hard for me to say when i= t will be fixed. I'll give an update on the next week. >=20 > Hi Vladimir, >=20 > Thank you so much. >=20 > 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 P= 4 or lower. If the same issue can be observed on a target that is secondary or primary t= hat would change this aspect. Richard=20 > Johann >=20 >=20 >>> Simple test cases are, for example >>>=20 >>> #define PORT (*((unsigned char volatile*) 0x24)) >>>=20 >>> unsigned short var16; >>>=20 >>> void func (void) >>> { >>> if (2048000ul * var16 > 1200000ul) >>> PORT |=3D 1; >>> } >>>=20 >>> When I compile it with >>>=20 >>> $ avr-gcc -Os bloat1.c -c && avr-size bloat1.o >>>=20 >>> the code size increases from 36 bytes (v8) to 88 bytes (v13). >>>=20 >>> Apart from that, register pressure is much higher because a frame pointe= r is set up for no reason, and the values go through stack slots for no reas= on. >>>=20 >>> Even test cases which don't require any code like >>>=20 >>> long func2 (void) >>> { >>> long var32; >>> __asm ("; some code %0" : "=3Dr" (var32)); >>> return var32; >>> } >>>=20 >>> increase in register pressure (x2), stack usage (from 0 to 6 bytes) and c= ode size from 2 bytes (v8) to 34 bytes (v13). >>>=20 >>> 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 >>>=20 >>> 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=3D have no= effect. >>>=20 >>> To configure, I used --target=3Davr --disable-nls --with-dwarf2 --enable= -languages=3Dc,c++ --with-gnu-as --with-gnu-ld --disable-shared, so nothing s= pecial. >>>=20 >>> The problem is present in v9, v10, v11, v12 and master (future v13), so s= itting around for quite a while, so maybe it's not fixed because RA maintain= ers are not aware of the problem.