From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28457 invoked by alias); 24 Oct 2012 09:27:52 -0000 Received: (qmail 28446 invoked by uid 22791); 24 Oct 2012 09:27:51 -0000 X-SWARE-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00,DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,KHOP_RCVD_TRUST,NML_ADSP_CUSTOM_MED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-ea0-f175.google.com (HELO mail-ea0-f175.google.com) (209.85.215.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 24 Oct 2012 09:27:46 +0000 Received: by mail-ea0-f175.google.com with SMTP id c1so96205eaa.20 for ; Wed, 24 Oct 2012 02:27:45 -0700 (PDT) Received: by 10.14.214.2 with SMTP id b2mr20686182eep.32.1351070865193; Wed, 24 Oct 2012 02:27:45 -0700 (PDT) Received: from sandifor-thinkpad.stglab.manchester.uk.ibm.com (gbibp9ph1--blueice2n1.emea.ibm.com. [195.212.29.75]) by mx.google.com with ESMTPS id z43sm24795783een.16.2012.10.24.02.27.43 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Oct 2012 02:27:44 -0700 (PDT) From: Richard Sandiford To: Eric Botcazou Mail-Followup-To: Eric Botcazou ,gcc-patches@gcc.gnu.org, rdsandiford@googlemail.com Cc: gcc-patches@gcc.gnu.org Subject: Re: [MIPS] Implement static stack checking References: <17103666.Uvnd1BXjPp@polaris> <13512041.RoNdtRD1f9@polaris> <873916noia.fsf@talisman.home> <11960832.jykuUikjBz@polaris> Date: Wed, 24 Oct 2012 09:30:00 -0000 In-Reply-To: <11960832.jykuUikjBz@polaris> (Eric Botcazou's message of "Wed, 24 Oct 2012 10:20:05 +0200") Message-ID: <87a9vcb4oh.fsf@sandifor-thinkpad.stglab.manchester.uk.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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 X-SW-Source: 2012-10/txt/msg02148.txt.bz2 Eric Botcazou writes: >> But why do we want the loop at all if the rounded size is zero? >> It's a compile-time constant after all. > > Yes, this never occurs in practice because of the value set for PROBE_INTERVAL > and STACK_CHECK_PROTECT. This can only occur in the dynamic case handled in > explow.c:probe_stack_range. > > All the stack checking code, in the middle-end and the various back-ends, use > a uniform implementation. This can probably be optimized a bit, but I'm not > sure it's really worth the hassle. But wouldn't the target independent "store zero" code (e.g. for alloca) be emitted at expand time, and optimised in the normal way? I'd hope jump threading etc. would then give something like the 3-insn form in cases where the constant is known to be nonzero. The problem here is that we're just writing asm directly, and in that case using the 3-insn 1-branch form seems better than the 4-insn 2-branch one. It's less code too :-) Richard