From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20103 invoked by alias); 17 Oct 2004 17:04:39 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 20093 invoked from network); 17 Oct 2004 17:04:37 -0000 Received: from unknown (HELO www.eyesopen.com) (208.41.78.163) by sourceware.org with SMTP; 17 Oct 2004 17:04:37 -0000 Received: from localhost (roger@localhost) by www.eyesopen.com (8.11.6/8.11.6) with ESMTP id i9HG8Rp30736; Sun, 17 Oct 2004 10:08:27 -0600 Date: Sun, 17 Oct 2004 17:07:00 -0000 From: Roger Sayle To: Eric Botcazou cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Fix PR middle-end/17813 In-Reply-To: <200410171519.34999.ebotcazou@libertysurf.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-10/txt/msg01382.txt.bz2 On Sun, 17 Oct 2004, Eric Botcazou wrote: > > A slight improvement might be to add a new ignore_pending_stack_adjust > > function (like clear_pending_stack_adjust) that resets stack_pointer_delta > > and pending_stack_adjust to zero, and call that in emit_stack_restore. > > I have 3 remarks/questions: > - what about discard_pending_stack_adjust instead? I think that "ignore" > could fool people into thinking that the stack adjustment is only temporarily > suspended. Sure. > - what about changing clear_pending_stack_adjust into > maybe_discard_pending_stack_adjust? The rationale is that the typical > idiom is currently: > > clear_pending_stack_adjust (); > do_pending_stack_adjust (); > > which seems odd at best. I'll agree that the semantics of clear_pending_stack_adjust are a bit strange, i.e. that this function is occassionally a no-op even if there's a pending stack adjustment. And it does indeed look like, with the single exception of expand_call in calls.c, all uses of clear_pending_stack_adjust are followed by do_pending_stack_adjust, so an interface/API clean-up (simplification) might be a good thing. Especially as expand_call's exceptional use looks like a good candidate for the proposed discard_pending_stack_adjust. > - I think that stack_pointer_delta should not be reset to zero for strict > correctness, and instead the same adjustment should be made in the new > function as in clear_pending_stack_adjust. Probably. I'll admit that I didn't fully investigate exactly how stack_pointer_delta needs to be updated in discard_pending_stack_adjust, just that it needs to be updated (which is why init_pending_stack_adjust isn't suitable). I'd need to read through more code to convince myself that a non-zero stack pointer delta is correct/safe for these builtins. Roger --