From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22929 invoked by alias); 7 Jun 2017 18:37:01 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 22544 invoked by uid 89); 7 Jun 2017 18:37:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wm0-f65.google.com Received: from mail-wm0-f65.google.com (HELO mail-wm0-f65.google.com) (74.125.82.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Jun 2017 18:36:58 +0000 Received: by mail-wm0-f65.google.com with SMTP id 70so3841632wme.1 for ; Wed, 07 Jun 2017 11:37:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:in-reply-to:references:mime-version :content-transfer-encoding:subject:to:cc:from:message-id; bh=YieZFD7nDl1XFovss+FrIqcmWT6XvxAoy36EdGNr6y8=; b=lTPydrR76UX7q4k6pD+2krq4jxv7GOrNqYEAEIJubeIYQCe+Iz1ocEQe3cwgfQ/ern KktynsFpqimFxAfEZaoyc92G/SpT6X7ux+lsrIOMc6+5HSFu5cAEX3tCEYUDQBMdMorU COC9DOm30ph6OZJGRtmuc1lAarFp/Gq49GGLfaYWOY+uWKdPpEU2l0NB7YwxcdluHLY3 9ohzxudVNbNYVi6MCiZe15sJlPt1Ml/uztF28MNwNaGTKDy3D/U2aioTzKLnP/sAqIgb mBPJ5j3BX3xEetY5HXU2N6FAXUEPWI92qFHBPex0T5KHX9TsmVijUazL64xC+ZtvtDvO lQDQ== X-Gm-Message-State: AODbwcAat/3UsN7rurCcNVKzHhySdQZwJG0gP0p2DtzfSYw1jQo5ZcQK q7VFvAE58ZzAqVmbmLg= X-Received: by 10.80.131.5 with SMTP id 5mr25229276edh.134.1496860620695; Wed, 07 Jun 2017 11:37:00 -0700 (PDT) Received: from [10.45.19.95] (213-225-36-228.nat.highway.a1.net. [213.225.36.228]) by smtp.gmail.com with ESMTPSA id d37sm1298279edb.54.2017.06.07.11.36.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jun 2017 11:36:59 -0700 (PDT) Date: Wed, 07 Jun 2017 18:37:00 -0000 In-Reply-To: <96b534c4-988f-e958-f341-9674a60aeb1e@gmail.com> References: <96b534c4-988f-e958-f341-9674a60aeb1e@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH] handle bzero/bcopy in DSE and aliasing (PR 80933, 80934) To: gcc-patches@gcc.gnu.org,Martin Sebor ,Richard Biener CC: Gcc Patch List From: Bernhard Reutner-Fischer Message-ID: <656E3329-B549-490D-A87F-7421D424E781@gmail.com> X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg00456.txt.bz2 On 7 June 2017 16:46:53 CEST, Martin Sebor wrote: >On 06/07/2017 02:23 AM, Richard Biener wrote: >> On Wed, Jun 7, 2017 at 5:26 AM, Martin Sebor >wrote: >>>> Note I'd be _much_ more sympathetic to simply canonicalizing all of >>>> bzero and bcopy >>>> to memset / memmove and be done with all the above complexity. >>> >>> >>> Attached is an updated patch along these lines. Please let me >>> know if it matches your expectations. >> >> I think you attached the wrong patch. > >Yes I did, sorry. The correct one is attached. Under POSIX.1-2008 "optimizing" bzero or bcmp is IMO plain wrong. It's like optimizing foo() to a random built-in but maybe that's just me. I= f your libc provides a define to a standard function for these under a comp= at knob then fine but otherwise you should fix that. *shrug*. Joseph? thanks, > >Martin > >> >> Richard. >> >>> FWIW, although I don't feel too strongly about bzero et al. I'm >>> not sure that this approach is the right one in general. It might >>> (slightly) simplify GCC itself, but other than the incidental code >>> generation improvement, it offers no benefit to users. In some >>> cases, it even degrades user experience by causing GCC issue >>> diagnostics that refer to functions that don't appear in the source >>> code, such as for: >>> >>> char d[1]; >>> >>> void* f (const void *p) >>> { >>> bzero (d, 7); >>> } >>> >>> warning: =E2=80=98__builtin_memset=E2=80=99 writing 7 bytes into a re= gion of size >1 >>> overflows the destination [-Wstringop-overflow=3D] >>> >>> For some functions like mempcpy it might even worse code overall >>> (slower and bigger). >>> >>> In other cases (like profiling) it loses interesting information. >>> >>> I think these types of transformations would be justified f they >>> were done based on measurably improved efficiency of the generated >>> code, but I'm uneasy about swapping calls to one function for >another >>> solely because it simplifies the implementation. Not least because >>> it doesn't seem like a viable general approach to simplifying the >>> implementation. >>> >>> Martin >>> >>> PS I stopped short of simplifying GCC to remove the existing special >>> handling of these three built-ins. If the patch is approved I'm >>> willing to do the cleanup in a subsequent pass.