From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106057 invoked by alias); 18 Sep 2018 19:46:35 -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 106046 invoked by uid 89); 18 Sep 2018 19:46:34 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 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-qt0-f195.google.com Received: from mail-qt0-f195.google.com (HELO mail-qt0-f195.google.com) (209.85.216.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 18 Sep 2018 19:46:33 +0000 Received: by mail-qt0-f195.google.com with SMTP id t39-v6so2895413qtc.8 for ; Tue, 18 Sep 2018 12:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=nC/1Jg1jQPTgpyaY4SDORbtFrhPAmdLeu8Fsa8guAp4=; b=oCLKpw5FmdjQ1liXDvIEd76C1Jg831xnmYo4LKuiqYEUaOiE5HJ6TERO6ptnUsqh1g HTHXtvk5JWf9wigHZrRoJaBeWaJxKFthRVDofRpxprldRm2f3CtgRHCp1Fu+4O66W2c3 9LU3u2MnpRWpUW5JTE5FcbdDENO+l2iZ2CXzJ6W5pF4SttcFzntoLaYfXeUm1PqDZSyr /Oz6IBtPmuyooFixeuEA3vfAIzaLjJiIhWV8wcYjOPart2TAxjM1EWO612mPrBrzc7dM WNkRU+gN5PLYGVyoglepqWuf0C03G548YUJ9TQqmkurr9v7+6eTYPxEoTqP7PzT8suap 2A0A== Return-Path: Received: from localhost.localdomain (97-118-105-75.hlrn.qwest.net. [97.118.105.75]) by smtp.gmail.com with ESMTPSA id 11-v6sm1403477qkk.54.2018.09.18.12.46.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Sep 2018 12:46:29 -0700 (PDT) Subject: Re: [PATCH] look harder for MEM_REF operand equality to avoid -Wstringop-truncation (PR 84561) To: Jeff Law , Richard Biener References: <6c2126fa-32b3-693b-e3da-cf70391710bf@gmail.com> <346c0950-ac9e-b7b4-799f-a8b661f7d55b@gmail.com> <9ca1c7dc-041a-3e15-a191-34d16a68aa2f@gmail.com> <1555c8f2-019a-1164-d1cc-650b78230c63@redhat.com> <26c29db3-6e0c-7df4-c779-cf01e958c654@gmail.com> <51ebb626-7207-edf8-9a70-c1ec525d24f3@gmail.com> <16290c2f-6203-7709-e7ec-1d56de6c20a2@redhat.com> Cc: GCC Patches From: Martin Sebor Message-ID: Date: Tue, 18 Sep 2018 20:01:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <16290c2f-6203-7709-e7ec-1d56de6c20a2@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-09/txt/msg01023.txt.bz2 On 09/18/2018 12:58 PM, Jeff Law wrote: > On 9/18/18 11:12 AM, Martin Sebor wrote: > >>> My bad. Sigh. CCP doesn't track copies, just constants, so there's not >>> going to be any data structure you can exploit. And I don't think >>> there's a value number you can use to determine the two objects are the >>> same. >>> >>> Hmm, let's back up a bit, what is does the relevant part of the IL look >>> like before CCP? Is the real problem here that we have unpropagated >>> copies lying around in the IL? Hmm, more likely the IL looksl ike: >>> >>> _8 = &pb_3(D)->a; >>> _9 = _8; >>> _1 = _9; >>> strncpy (MEM_REF (&pb_3(D)->a), ...); >>> MEM[(struct S *)_1].a[n_7] = 0; >> >> Yes, that is what the folder sees while the strncpy call is >> being transformed/folded by ccp. The MEM_REF is folded just >> after the strncpy call and that's when it's transformed into >> >> MEM[(struct S *)_8].a[n_7] = 0; >> >> (The assignments to _1 and _9 don't get removed until after >> the dom walk finishes). >> >>> >>> If we were to propagate the copies out we'd at best have: >>> >>> _8 = &pb_3(D)->a; >>> strncpy (MEM_REF (&pb_3(D)->a), ...); >>> MEM[(struct S *)_8].a[n_7] = 0; >>> >>> >>> Is that in a form you can handle? Or would we also need to forward >>> propagate the address computation into the use of _8? >> >> The above works as long as we look at the def_stmt of _8 in >> the MEM_REF (we currently don't). That's also what the last >> iteration of the loop does. In this case (with _8) it would >> be discovered in the first iteration, so the loop could be >> replaced by a simple if statement. >> >> But I'm not sure I understand the concern with the loop. Is >> it that we are looping at all, i.e., the cost? Or that ccp >> is doing something wrong or suboptimal? (Should have >> propagated the value of _8 earlier?) > I suspect it's more a concern that things like copies are typically > propagated away. So their existence in the IL (and consequently your > need to handle them) raises the question "has something else failed to > do its job earlier". > > During which of the CCP passes is this happening? Can we pull the > warning out of the folder (even if that means having a distinct warning > pass over the IL?) It happens during the third run of the pass. The only way to do what you suggest that I could think of is to defer the strncpy to memcpy transformation until after the warning pass. That was also my earlier suggestion: defer both it and the warning until the tree-ssa-strlen pass (where the warning is implemented to begin with -- the folder calls into it). Martin