From patchwork Tue Jul 26 02:33:19 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joern Rennecke X-Patchwork-Id: 106774 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 513F6B6F8C for ; Tue, 26 Jul 2011 12:33:48 +1000 (EST) Received: (qmail 9790 invoked by alias); 26 Jul 2011 02:33:45 -0000 Received: (qmail 9776 invoked by uid 22791); 26 Jul 2011 02:33:44 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL, BAYES_00, MIME_QP_LONG_LINE X-Spam-Check-By: sourceware.org Received: from c60.cesmail.net (HELO c60.cesmail.net) (216.154.195.49) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 26 Jul 2011 02:33:21 +0000 Received: from unknown (HELO epsilon2) ([192.168.1.60]) by c60.cesmail.net with ESMTP; 25 Jul 2011 22:33:19 -0400 Received: from e178039015.adsl.alicedsl.de (e178039015.adsl.alicedsl.de [85.178.39.15]) by webmail.spamcop.net (Horde MIME library) with HTTP; Mon, 25 Jul 2011 22:33:19 -0400 Message-ID: <20110725223319.petrcv01csccs44s-nzlynne@webmail.spamcop.net> Date: Mon, 25 Jul 2011 22:33:19 -0400 From: Joern Rennecke To: Jiangning Liu Cc: gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org, vmakarov@redhat.com, dje.gcc@gmail.com, Richard Henderson , Ramana Radhakrishnan , 'Ramana Radhakrishnan' Subject: RE: [RFC] Add middle end hook for stack red zone size References: <4e255312.0a852b0a.528d.6933SMTPIN_ADDED@mx.google.com> <001e01cc4b33$6d3818f0$47a84ad0$@liu@arm.com> In-Reply-To: <001e01cc4b33$6d3818f0$47a84ad0$@liu@arm.com> MIME-Version: 1.0 User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Quoting Jiangning Liu : > Hi, > > One month ago, I sent out this RFC to *gcc-patches* mail list, but I > didn't receive any response yet. So I'm forwarding this mail to > *gcc* mail list. Can anybody here really give feedback to me? Well, I couldn't approve any patch, but I can point out some issues with your patch. First, it's missing a ChangeLog, and you don't state how you have tested it. And regarding the code in sched_analyze_1, I think you'll get false positives with alloca, and false negatives when registers are involved to compute offsets or to restore the stack pointer from. FWIW, I think generally blunt scheduling barriers should be avoided, and instead the dependencies made visible to the scheduler. E.g., I've been working with another architecture with a redzone, where at -fno-omit-frame-pointer, the prologue can put pretend_args into the redzone, then after stack adjustment and frame allocation, these arguments are accessed via the frame pointer. With the attached patchlet, alias analysis works for this situation too, so no blunt scheduling block is required. Likewise, with stack adjustments, they should not affect scheduling in general, but be considered to clobber the part of the frame that is being exposed to interrupt writes either before or after the adjustment. At the moment, each port that wants to have such selective scheduling blockages has to define a stack_adjust pattern with a memory clobber in a parallel, with a memref that shows the high water mark of possible interrupt stack writes. Prima facia it would seem convenient if you only had to tell the middle-end about the redzone size, and it could figure out the implicit clobbers when the stack is changed. However, when a big stack adjustment is being made, or the stack is realigned, or restored from the frame pointer / another register where it was saved due to realignment, the adjustment is not so obvious. I'm not sure if you can actually create an robust interface that's simpler to use than putting the right memory clobber in the stack adjust pattern. Note also that the redzone size can vary from function to function depending on ABI-altering attributes, in particular for interrupt functions, which can also have different incoming and outgoing redzone sizes. Plus, you can have an NMI / reset handler which can use the stack like an ordinary address register. 2009-09-23 Joern Rennecke * alias.c (base_alias_check): Allow for aliases between stack- and frame-pointer referenced memory. Index: alias.c =================================================================== --- alias.c (revision 1646) +++ alias.c (revision 1647) @@ -1751,6 +1751,17 @@ base_alias_check (rtx x, rtx y, enum mac if (GET_CODE (x_base) != ADDRESS && GET_CODE (y_base) != ADDRESS) return 0; + /* If both are stack references, one via the stack pointer, the other via + the frame pointer, there can be an alias. + E.g.: gcc.c-torture/execute/20041113-1.c -O3 -g */ + if (GET_CODE (x_base) == ADDRESS + && (XEXP (x_base, 0) == stack_pointer_rtx + || XEXP (x_base, 0) == hard_frame_pointer_rtx) + && GET_CODE (y_base) == ADDRESS + && (XEXP (y_base, 0) == stack_pointer_rtx + || XEXP (y_base, 0) == hard_frame_pointer_rtx)) + return 1; + /* If one address is a stack reference there can be no alias: stack references using different base registers do not alias, a stack reference can not alias a parameter, and a stack reference