From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122636 invoked by alias); 14 Oct 2015 08:29:42 -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 122623 invoked by uid 89); 14 Oct 2015 08:29:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: smtp.eu.adacore.com Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 14 Oct 2015 08:29:41 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 1FC2C279EBDA; Wed, 14 Oct 2015 10:29:38 +0200 (CEST) Received: from smtp.eu.adacore.com ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFo5TViinZLm; Wed, 14 Oct 2015 10:29:38 +0200 (CEST) Received: from polaris.localnet (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id E87D8279EBCA; Wed, 14 Oct 2015 10:29:37 +0200 (CEST) From: Eric Botcazou To: Richard Henderson Cc: gcc-patches@gcc.gnu.org, Bernd Schmidt , Abe , Sebastian Pop , Kyrill Tkachov Subject: Re: using scratchpads to enhance RTL-level if-conversion: revised patch Date: Wed, 14 Oct 2015 08:29:00 -0000 Message-ID: <1975913.Fx1EfbHjAv@polaris> User-Agent: KMail/4.14.9 (Linux/3.16.7-24-desktop; KDE/4.14.9; x86_64; ; ) In-Reply-To: <561DAA48.60604@redhat.com> References: <5615AADE.4030306@yahoo.com> <56166E68.2040004@redhat.com> <561DAA48.60604@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-SW-Source: 2015-10/txt/msg01322.txt.bz2 > If you're using one of the switches that checks for stack overflow at the > start of the function, you certainly don't want to do any such stores. There is a protection area for -fstack-check (STACK_CHECK_PROTECT bytes) so you can do stores just below the stack pointer as far as it's concerned. There is indeed the issue of the mere writing below the stack pointer. Our experience with various OSes and architectures shows that this almost always works. The only problematic case is x86{-64}/Linux historically, where you cannot write below the page pointed to by the stack pointer (that's why there is a specific implementation of -fstack-check for x86{-64}/Linux). -- Eric Botcazou