From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129073 invoked by alias); 14 Oct 2015 17:46:27 -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 129047 invoked by uid 89); 14 Oct 2015 17:46:26 -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,SPF_HELO_PASS,T_RP_MATCHES_RCVD 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; Wed, 14 Oct 2015 17:46:26 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id B9F3DA0B8C; Wed, 14 Oct 2015 17:46:24 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-105.phx2.redhat.com [10.3.113.105]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9EHkNNl012010; Wed, 14 Oct 2015 13:46:24 -0400 Subject: Re: using scratchpads to enhance RTL-level if-conversion: revised patch To: Eric Botcazou , Richard Henderson References: <5615AADE.4030306@yahoo.com> <56166E68.2040004@redhat.com> <561DAA48.60604@redhat.com> <1975913.Fx1EfbHjAv@polaris> Cc: gcc-patches@gcc.gnu.org, Bernd Schmidt , Abe , Sebastian Pop , Kyrill Tkachov From: Jeff Law Message-ID: <561E94EF.8000209@redhat.com> Date: Wed, 14 Oct 2015 17:46:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <1975913.Fx1EfbHjAv@polaris> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg01403.txt.bz2 On 10/14/2015 02:28 AM, Eric Botcazou wrote: >> 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). It was problematical on the PA, but I can't recall precisely why. The thing we need to remember here is that if we do somethig like use space just below the stack pointer, valgrind is probably going to start complaining (and legitimately so). While we know the result is throw-away, valgrind doesn't and the complains and noise from this would IMHO outweigh the benefits from using the trick of reading outside the defined stack area. jeff