From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 705E9385DC09; Tue, 19 Dec 2023 08:03:15 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 705E9385DC09 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1702972995; bh=dgiWj1dHINp55dh71NuwKFj2XtLgRqExtrkj5amG4PE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=To/1YyguFOTcUlv951UIAgd5+wjwLZoDOyPHb8RMMB7LV5D9m2mQZvTGMb7Dghb8s eVDd4B8lOQgG2tHh8nZj0fJzPPxzg/YleHv8GgKnmvt0qrIxif091aD15rqUyawI6e mBiyZ+Q2ofANVlF75x3TdSJDMTOL6LWmud8ohbJk= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/56888] memcpy implementation optimized as a call to memcpy Date: Tue, 19 Dec 2023 08:03:11 +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: 4.8.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D56888 --- Comment #49 from Richard Biener --- (In reply to M Welinder from comment #48) > It's your (1). gcc is changing a program that can rely on errno not being > changed to one where the C library can change it. (The current C library= or > any future library that the resulting binary may be dynamically linked > against.) Ick. Standards continue to surprise me ;) > Is there any real-world situation that benefits from introducing these > calls? It has the feel of optimizing for a benchmark. People are good in writing inefficient code and replacing say, an open coded strlen by an actual call to strlen enables followup transforms that rely on strlen appearing as strlen and not an open-coded variant (I realize that technically one might find a way to implement that without actually emitting a call in the end). And yes, optimizing (repeated) calls of strlen or replacing open-coded large memcpy by a library call to optimized functions can make a noticable difference even for non-benchmarks. We're currently generating calls to memcpy, memmove, memset and strlen. We are also replacing memmove with memcpy, printf with puts or putc, all of those transforms are then invalid because of (1) as well. We are treating -fno-math-errno as applying to non-math functions and we don't have any -fno-errno or way of analyzing/annotating whether a program is interested in the state of errno (not only but mainly because identifying accesses to errno is non-trivial). Note this issue (invalid because of (1)) should probably be split out to a separate bug.=