From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75340 invoked by alias); 29 Jan 2016 15:41:53 -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 75330 invoked by uid 89); 29 Jan 2016 15:41:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1788, lucky, thankful, trapping 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, 29 Jan 2016 15:41:51 +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 1E07E19CBED; Fri, 29 Jan 2016 15:41:50 +0000 (UTC) Received: from tucnak.zalov.cz ([10.3.113.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0TFfmpq028831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 29 Jan 2016 10:41:49 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id u0TFfi3X020824; Fri, 29 Jan 2016 16:41:45 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id u0TFffJi020823; Fri, 29 Jan 2016 16:41:41 +0100 Date: Fri, 29 Jan 2016 15:41:00 -0000 From: Jakub Jelinek To: Bernd Schmidt Cc: Eric Botcazou , Richard Sandiford , gcc-patches@gcc.gnu.org, Matthew Fortune , Bernd Edlinger , Nick Clifton Subject: Re: Is it OK for rtx_addr_can_trap_p_1 to attempt to compute the frame layout? (was Re: [PATCH] Skip re-computing the mips frame info after reload completed) Message-ID: <20160129154141.GS3017@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <6D39441BF12EF246A7ABCE6654B023536A705EB0@LEMAIL01.le.imgtec.org> <87y4bcavl5.fsf_-_@googlemail.com> <1634352.Ak3Qm2WKut@polaris> <56AABBC5.6090309@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56AABBC5.6090309@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg02316.txt.bz2 On Fri, Jan 29, 2016 at 02:09:25AM +0100, Bernd Schmidt wrote: > I'm on the fence; I do think the original problem is an issue we should fix, > but I'm also not terribly happy with the implementation we have right now. The fact that it has been only reported from generated testcases only means we are lucky nobody encountered it yet in real-world programs. Plus, we need to be thankful to people working on those generators that keep reporting GCC bugs, they significantly improve the compiler. > Besides the issues already mentioned, doesn't it kind of assume these > offsets are constant (which they definitely aren't, consider arg pushes for > example)? Sure, for some registers the offsets aren't constant. In some cases we e.g. have REG_ARGS_SIZE notes, but in other cases don't and don't have anything else that would help us understand the difference between current sp value and one at the end of the prologue or so. > I think a better approach might be to just mark accesses at known locations > in the frame, or arg pushes, as MEM_NOTRAP_P, and consider accesses with > non-constant or calculated offsets as potentially trapping. I don't see how that would work generally. Sure, if there is e.g. a constant offset array access, it could be checked easily, but if there is variable offset array access, that is at some point later on changed into a constant offset access, you'd need to be conservative, unless you can prove it is in range. Or perhaps we could also use some other flag (or turn it into __builtin_trap or __builtin_unreachable or whatever) to mark MEMs that are always invalid if executed. Jakub