From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32471 invoked by alias); 6 Nov 2015 18:44:25 -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 31570 invoked by uid 89); 6 Nov 2015 18:44:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 06 Nov 2015 18:44:24 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id AA8653B3C2; Fri, 6 Nov 2015 18:44:22 +0000 (UTC) Received: from localhost.localdomain (vpn1-4-157.ams2.redhat.com [10.36.4.157]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tA6IiKMb016815; Fri, 6 Nov 2015 13:44:21 -0500 Subject: Re: Remove noce_mem_write_may_trap_or_fault_p in ifcvt To: Jeff Law , Bernd Schmidt , GCC Patches , Jakub Jelinek , Sebastian Pop References: <563CE17F.6090308@t-online.de> <563CF3F0.8010703@redhat.com> From: Bernd Schmidt Message-ID: <563CF504.2070604@redhat.com> Date: Fri, 06 Nov 2015 18:44:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563CF3F0.8010703@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg00701.txt.bz2 On 11/06/2015 07:39 PM, Jeff Law wrote: > Given the name "..may_trap_or_fault_p" ISTM that its mode of operation > should be to return true (the safe value) unless we can prove the write > will not fault. The more cases we can prove true, the better AFAICT. > > The PLUS case looks totally wrong. Though it could possibly be made > correct by looking for [sp,fp,ap] + offset addresses and verifying we're > doing a mis-aligned write. We'd probably also need some kind of > sensible verification that the offset isn't too large/small. I'm guessing this is already covered by the call to may_trap_or_fault_p. The only additional thing that this function tries to prove is that the mem isn't readonly. IMO either MEM_READONLY_P is sufficient for that (and my patches operate under that assumption), or it isn't sufficient and no amount of checking the address is going to make the function useful. Bernd