From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id CA32E388A43D; Mon, 1 Feb 2021 15:46:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CA32E388A43D From: "david at westcontrol dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/98884] Implement empty struct optimisations on ARM Date: Mon, 01 Feb 2021 15:46:59 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: enhancement X-Bugzilla-Who: david at westcontrol dot com 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: 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2021 15:46:59 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D98884 --- Comment #6 from David Brown --- (In reply to Jakub Jelinek from comment #3) > If GCC and Clang are ABI incompatible on this, then one of the two compil= ers > is buggy. So, it is needed to look at the EABI and find out which case it > is. I've had a look at the ARM C++ ABI, to the best of my abilities: Section 4.1 has this to say: GC++ABI =C2=A72.27POD Data Types The GC++ABI defines the way in which empty class types are laid out. For t= he purposes of parameter passing in [AAPCS], a parameter whose type is an empty class shall be treated as if its type were an aggregate with a single membe= r of type unsigned byte. Note: Of course, the single member has undefined content. (This references ) If my reading is correct, then gcc is correct and clang is wrong here - emp= ty classes are treated as containing a single unsigned byte, and then expanded= to a 32-bit type before passing. (There is still no need to put a zero in the= se parameters, as the value is unspecified.) It may be that the x86 gcc port is wrong here, but I haven't looked at the details of x86 calling conventions. I hope someone can check this out, and a perhaps file a bug report for clan= g so that they can correct it. (Alternatively, file a bug report with ARM so th= at they can change the ABI!) However, in this particular case, if clang is wrong then I don't want to be right. I can see no benefit, and significant cost, in passing zeros for th= ese empty tag structs. I'd be quite happy with an explicitly non-conforming sw= itch to enable such optimisations (just like "-fshort-enums" or other switches t= hat mess with caller and callee registers). Or I'd be even happier to find that clang is wrong and gcc ARM gets optimised without a flag :-)=