From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F40FD385355C; Thu, 1 Sep 2022 07:24:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F40FD385355C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1662017059; bh=K/iI9DWL9rCflI7WcW7RX/EtMP6zp4JCU38qPKnYPV0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Hh4xf4uzaxmqKzVlSxkZeVfoxSOA4aDqSo78GfBhu/+SakzrjOIuc/k1Wt0iIMmvn r36rKGLfq4vn/VGTpz+y2S/decnal1XNgTfl3OuyYGGT97OxbxmHQs3cupDvlItcID bRdh9XApxwifErtpijm86VEa8bX2yTjcGYkddUmE= From: "kito at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/88345] -Os overrides -falign-functions=N on the command line Date: Thu, 01 Sep 2022 07:24:17 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 9.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: kito at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D88345 Kito Cheng changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kito at gcc dot gnu.org --- Comment #7 from Kito Cheng --- We are hitting this issue on RISC-V, and got some complain from linux kernel developers, but in different form as the original report, we found cold function or any function is marked as cold by `-fguess-branch-probability` = are all not honor to the -falign-functions=3DN setting, that become problem on = some linux kernel feature since they want to control the minimal alignment to ma= ke sure they can atomically update the instruction which require align to 4 by= te. However current GCC behavior can't guarantee that even -falign-functions=3D= 4 is given, there is 3 option in my mind: 1. Fix -falign-functions=3DN, let it work as expect on -Os and all cold fun= ctions 2. Force align to 4 byte if -fpatchable-function-entry is given, that's sho= uld be doable by adjust RISC-V's FUNCTION_BOUNDARY 3. Adjust RISC-V's FUNCTION_BOUNDARY to let it honor to -falign-functions= =3DN 4. Adding a -malign-functions=3DN...Okay, I know that suck idea, x86 already deprecated that. But I think ideally this should fixed by 1 option if possible. Testcase from RISC-V kernel guy: ``` /* { dg-do compile } */ /* { dg-options "-march=3Drv64gc -mabi=3Dlp64d -O1 -falign-functions=3D128"= } */ /* { dg-final { scan-assembler-times ".align 7" 2 } } */ // Using 128 byte align rather than 4 byte align since it easier to observe. __attribute__((__cold__)) void a() {} // This function isn't align to 128 b= yte void b() {} // This function align to 128 byte. ``` Proposed fix: ``` diff --git a/gcc/varasm.c b/gcc/varasm.c index 49d5cda122f..6f8ed85fea9 100644 --- a/gcc/varasm.c +++ b/gcc/varasm.c @@ -1907,8 +1907,7 @@ assemble_start_function (tree decl, const char *fnnam= e) Note that we still need to align to DECL_ALIGN, as above, because ASM_OUTPUT_MAX_SKIP_ALIGN might not do any alignment at all. = */ if (! DECL_USER_ALIGN (decl) - && align_functions.levels[0].log > align - && optimize_function_for_speed_p (cfun)) + && align_functions.levels[0].log > align) { #ifdef ASM_OUTPUT_MAX_SKIP_ALIGN int align_log =3D align_functions.levels[0].log; ```=