From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from elaine.keithp.com (home.keithp.com [63.227.221.253]) by sourceware.org (Postfix) with ESMTPS id 0E6B83858013; Wed, 3 Nov 2021 16:43:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0E6B83858013 Received: from localhost (localhost [127.0.0.1]) by elaine.keithp.com (Postfix) with ESMTP id B7AC83F310F8; Wed, 3 Nov 2021 09:43:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at keithp.com Received: from elaine.keithp.com ([127.0.0.1]) by localhost (elaine.keithp.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7dgtqhBLjmKf; Wed, 3 Nov 2021 09:43:11 -0700 (PDT) Received: from keithp.com (koto.keithp.com [192.168.11.2]) by elaine.keithp.com (Postfix) with ESMTPSA id 1193D3F310F6; Wed, 3 Nov 2021 09:43:11 -0700 (PDT) Received: by keithp.com (Postfix, from userid 1000) id DB7561E6013A; Wed, 3 Nov 2021 09:43:10 -0700 (PDT) From: Keith Packard To: Martin Sebor , gcc@gcc.gnu.org Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Add 'no_builtin' function attribute In-Reply-To: <9d952e88-d08f-c436-acab-2f89ee2950bb@gmail.com> References: <87r1by1qxg.fsf@keithp.com> <20211102211458.10233-1-keithp@keithp.com> <9d952e88-d08f-c436-acab-2f89ee2950bb@gmail.com> Date: Wed, 03 Nov 2021 09:43:10 -0700 Message-ID: <87y265ur4x.fsf@keithp.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2021 16:43:14 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Martin Sebor writes: > Can this option be used in attribute optimize? If yes, what's > the advantage of also providing an atttribute? Compatibility with the clang attribute. > It seems to me that as a matter of QOI, GCC should be able to > disable the expansion of built-ins to calls to themselves in > their bodies (I would view it as a bug if GCC expanded a byte > copying loop into a call to __builtin_memcpy in the body of > a function named memcpy, without issuing a warnings; but even > with a warning I'd hope it to do the sensible thing and avoid > introducing infinite recursion). That's a pretty sensible plan and would resolve many of the issues caused by these optimizations while implementing libc itself. Of course, that wouldn't fix other places where the compiler is using knowledge of builtin semantics to drive optimization (like the memset call before free). > A compiler may not be able > to do that in calls made from those functions, and for that > the built-in expansion needs to be disabled explicitly. > -fno-builtin isn't good enough because it doesn't prevent GCC > from introiducing calls to __builtin_ functions, and that's > what this feature is for. Do I understand correctly? =2Dfno-builtin has two problems: 1. Cannot be used in source code, only on the command line. 2. Also disables explicit use of builtin functions. > If we end up adding a new attribute (as opposed to relying > on attribute optimize) and the attribute is expected to have > an effect only on the definitions of functions and not also > on their callers, I would suggest to consider having > the handler check that it is, in fact, on a definiton and > not a declaration and issuing a warning that it has no effect > on a declaration, to avoid misunderstandings. Hrm. I copied the code from the 'optimize' attribute to make this have the same effect; as above, this new attribute offers clang compatibility for something that can also be done with the existing optimize attribute. > If either a new attribute or a new option is introduced they > need to be documented in the manual. From your description > it's not clear to me if it's just about disabling the expansion > of the built-ins or if it's meant to prevent GCC from making > any assumptions about their semantics in calls to the annotated > functions. That will likely be of interest to users and it > matters for diagnostics. Yes, I definitely need to add documentation. I'm actually using this thread to help clarify precisely what those semantics should be; it's a pretty subtle operation when compared with -fno-builtin. > We will also need to add tests for the feature. There are many > built-ins in GCC but the patch only affects a small subset of > them (e.g., I see it affects a few stdio and string functions > but I'm not sure the printf family are among them -- all those > handled in gimple-ssa-sprintf.c). Yeah, I can get started on tests. Keeping this operation from affecting things that it shouldn't while hitting everything it should is a bit more difficult than I had hoped; I suspect we'll be finding cases for some time unless I can discover an easier place to hook this into. > Besides its effect on codegen, I would also hope for a few test > cases for warnings, those issued by the strlen pass in particular, > to make sure their effects either are preserved or are disabled > (whichever is appropriate). Because the goal is to have the optimizer "forget" about the semantics of builtins, but let them still be used when explicitly named in the code, these warnings would still need to be enabled, so I left them in. I think we need to get a clear description of what this attribute should do before making many more changes in the code. Here's a first stab: no_builtin This attribute directs GCC to not use knowledge of the semantics of built-in functions to direct code optimization. GCC will not add or remove usage of builtin functions, or restructure code in ways that depend on built-in knowledge of their operation. Explicit use of builtin functions will still use any internal implementations. In contrast to -fno-builtin, the no_builtin attribute does not disable declaration of the built-in functions, so messages related to use and definition will still be enabled, and they can still be used when named explicitly. In addition, the no_builtin attribute can be applied on a function-at-a-time level, while -fno-builtin must be specified on the command line. =2D-=20 =2Dkeith --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAmGCvB4ACgkQ2yIaaQAA ABHCIQ//ct/LXV+bYyAs+MSYfBJmpTaqSmDSZ3yVvpxA9qEvc3aKBNkHTqw3DG2d oSJNIlnlE6/9mkpj5sf6IIGjjc7vUQl7I8yhRGkGMB1gyY8DFSeGrYhC4QVxuKM+ GO8Hn+ObG3xykpypgqVJ4VByqF9BzbMFeTuSrxY/gLO624X8gDP+jRvBdlqRfkDc z7W1iIszJQL/Cd2/h/TM7Iaq9fPaibdGSVd6TJ26A7J46o56w6EKOMKXUI+jSwwg kluhkCfLXkxTFkhNp7JOCVMiNuxc9MV75ab6p6WTxvD4vXl97yClMGfJBOiCGpty 0LGzU7631F/KPl4UIxchuDRQWqMcEJ+Ezg2BLsvQ44elIYdWv611Eih3fZEoHNF1 1xCYCeRYnDvryJ3bSSmvnvI6ylZoLvIOIlYcyBsp1FAt4sD7b3ddEPKar6PsfMQ0 ZPhUCVUgBKuM/IavVzPaD5S1khSfNo43G2IfP0WHlZ6DZWW8jeM7PSe9uNFr2tzF OjuSXM34aMa8ZE6CBQmwPxN8hAYW3gz9Um2BVR3pc1iDuNQY6SptUMmmYwG+r/J+ tvs0ycBcYFAd7NEG6gFIDRzHFutexIqggj689/yX9YjOaLzpKYD3u/5HGU8g+aRX djjBOIqqO9gQ+n5hPJAKzUqZ8axRc3av2ASqOsA9E6W6ve1PljE= =moe/ -----END PGP SIGNATURE----- --=-=-=--