From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68737 invoked by alias); 9 Jun 2017 12:35:46 -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 67966 invoked by uid 89); 9 Jun 2017 12:35:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 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-ot0-f193.google.com Received: from mail-ot0-f193.google.com (HELO mail-ot0-f193.google.com) (74.125.82.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 Jun 2017 12:35:43 +0000 Received: by mail-ot0-f193.google.com with SMTP id k4so5777356otd.0 for ; Fri, 09 Jun 2017 05:35:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nWb1hXOwk2xe38Qh/c4xNUndKDd3XCUS8tnQhcqaWTg=; b=m1EcZoXA+nDYbJAwZakv/U3jBC3U8WB0diT/yedG74s/fnKLWIjgLaEYzk1lF1REdB du9ukrf9Y9Ya33X2XoywtRbVR2s2qcEvy+f+U1jGaAOM6b3tQIsGgmgTgxPa31h+u+2R V7MfTfJhYrOxsB+2TuW8LEJO/1KGLGi1uX/tW4xRUSE3k7N1D/D5SdKT0pLiExQzxYZF bztCYILV3mvL1IQZ0AzXiCtKNdqHxgxpeHGyQozbI74B0M9Al9coalquRMWHbYJEUs/q uUqCifFrS15l0T699c8pJ58NIUxyw+zplV1hxlqXQCVqhERVmzL/t5QMRNxd0FkS26b9 +Bag== X-Gm-Message-State: AKS2vOzDTsh9eOTdfo+wmh6aOGYcovrHstKodpu5tZKsyXhqCvazu5PG GOmbzCVchcYKZgXP5hWkWyl5b8nDcK0GBqk= X-Received: by 10.157.27.219 with SMTP id v27mr5474724otv.237.1497011746157; Fri, 09 Jun 2017 05:35:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.36.8 with HTTP; Fri, 9 Jun 2017 05:35:45 -0700 (PDT) In-Reply-To: <132d2724-8e3a-bb1b-731f-0c0d1e7883d6@gmail.com> References: <96b534c4-988f-e958-f341-9674a60aeb1e@gmail.com> <656E3329-B549-490D-A87F-7421D424E781@gmail.com> <87936043-98aa-52e5-155b-38ecafca562c@gmail.com> <67a113e7-ee14-8afe-9deb-6c2c26927505@gmail.com> <132d2724-8e3a-bb1b-731f-0c0d1e7883d6@gmail.com> From: Richard Biener Date: Fri, 09 Jun 2017 12:35:00 -0000 Message-ID: Subject: Re: [PATCH] handle bzero/bcopy in DSE and aliasing (PR 80933, 80934) To: Martin Sebor Cc: GCC Patches , Bernhard Reutner-Fischer Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg00610.txt.bz2 On Thu, Jun 8, 2017 at 6:29 PM, Martin Sebor wrote: > On 06/08/2017 01:51 AM, Richard Biener wrote: >> >> On Thu, Jun 8, 2017 at 4:33 AM, Martin Sebor wrote: >>> >>> On 06/07/2017 02:12 PM, Martin Sebor wrote: >>>> >>>> >>>> On 06/07/2017 02:01 PM, Marc Glisse wrote: >>>>> >>>>> >>>>> On Wed, 7 Jun 2017, Bernhard Reutner-Fischer wrote: >>>>> >>>>>> 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. If your libc provides a define to a standard function for these >>>>>> under a compat knob then fine but otherwise you should fix that. >>>>>> *shrug*. Joseph? >>>>> >>>>> >>>>> >>>>> The patch optimizes __builtin_bzero, which should be ok. The question >>>>> (independent from this patch) is then under what conditions bzero >>>>> should >>>>> be detected as a builtin. >>>> >>>> >>>> >>>> Yes. The problem is that unlike for C and C++, GCC doesn't have >>>> a mechanism to select the target version of POSIX. I think it >>>> should. >>>> >>>> But there is a subtle problem with the patch that needs fixing. >>>> Bcopy should not be transformed to memcpy but rather memmove. >>>> I'll fix that before committing. >>> >>> >>> >>> Attached is an updated patch with this fix. I also added a cast >>> from bcopy and bzero to void to detect accidental uses of the >>> return value. Tested on x86_64-linux. >> >> >> Please do not add foldings to builtins.c but instead add them to >> gimple-fold.c. > > > Sure. Attached is an adjusted patch. > >> >> + /* Call memset and return the result cast to void to detect its use >> + (bzero returns void). */ >> + tree call = build_call_expr_loc (loc, fn, 3, dst, integer_zero_node, >> len); >> + return fold_convert (void_type_node, call); >> >> ??? How can the result be used if the original call result was not? > > > The cast ensured GCC would continue to warn on code like: > > void f (void *d, unsigned n) > { > return bzero (d, n); > } > > Without the cast (as in the first patch) the above was silently > accepted. > > This isn't necessary when the folding is done in gimple-fold.c. +static bool +gimple_fold_builtin_bcmp (gimple_stmt_iterator *gsi) +{ + /* Transform bcmp (a, b, len) into memcmp (a, b, len). */ + + gimple *stmt = gsi_stmt (*gsi); + tree a = gimple_call_arg (stmt, 0); + tree b = gimple_call_arg (stmt, 1); + tree len = gimple_call_arg (stmt, 2); + + gimple_seq seq = NULL; + gimple *repl = gimple_build_call (fn, 3, a, b, len); + gimple_seq_add_stmt_without_update (&seq, repl); + gsi_replace_with_seq_vops (gsi, seq); given they have the same prototype you can do like gimple_fold_builtin_stpcpy: gimple_call_set_fndecl (stmt, fn); fold_stmt (gsi); That works even with bcopy -> memmove if you swap arguments. Ok with that changes. Thanks, Richard. > Martin