From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59236 invoked by alias); 26 Jun 2015 21:28:50 -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 45895 invoked by uid 89); 26 Jun 2015 21:24:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS 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, 26 Jun 2015 21:24:25 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 9740B3674CC; Fri, 26 Jun 2015 21:24:23 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-49.phx2.redhat.com [10.3.113.49]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5QLOMi3001350; Fri, 26 Jun 2015 17:24:22 -0400 Message-ID: <558DC307.3060904@redhat.com> Date: Fri, 26 Jun 2015 21:29:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Richard Biener , Alan Lawrence , Sebastian Pop CC: Abe Skolnik , "gcc-patches@gcc.gnu.org" Subject: Re: fix PR46029: reimplement if conversion of loads and stores References: <20150612205047.GA27819@cc00.spa.sarc.sas> <55883757.8070105@arm.com> <558AE47E.7050408@redhat.com> <558D43C2.5000201@arm.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg01996.txt.bz2 On 06/26/2015 08:57 AM, Richard Biener wrote: > > Another possibility is to not share them and make sure to insert clobbers for them when they become dead so later stack slot sharing can merge them again. We've certainly had cases in the past where re-using a stack slot for an object that has gone out of scope for some other object in a different scope with a different type are not seen as conflicting by the aliasing machinery in the past resulting in incorrect code motions. Creating distinct scratchpads and letting the existing machinery (which has been fixed to deal with the issues noted above I believe) would make more sense than trying to reimplement the sharing correctness stuff within if-conversion. jeff