From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3455 invoked by alias); 1 Aug 2011 18:43:57 -0000 Received: (qmail 3444 invoked by uid 22791); 1 Aug 2011 18:43:56 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 01 Aug 2011 18:43:38 +0000 X-RZG-AUTH: :LXoWVUeid/7A29J/hMvvT2k715jHQaJercGOZE+TiTS5oyq6h4gi X-RZG-CLASS-ID: mo00 Received: from [192.168.2.100] (dslb-084-058-197-006.pools.arcor-ip.net [84.58.197.6]) by smtp.strato.de (cohen mo29) (RZmta 26.2) with ESMTPA id u007cfn71I0a2T ; Mon, 1 Aug 2011 20:43:11 +0200 (MEST) Message-ID: <4E36F3AF.3070300@gjlay.de> Date: Mon, 01 Aug 2011 18:43:00 -0000 From: Georg-Johann Lay User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: GCC Patches CC: Richard Henderson , bernds@codesourcery.com, iant@google.com, Denis Chertykov Subject: Re: [RFC] Cleanup DW_CFA_GNU_args_size handling References: <4E36D44A.6020607@redhat.com> In-Reply-To: <4E36D44A.6020607@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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: 2011-08/txt/msg00081.txt.bz2 Richard Henderson schrieb: > This is related primarily to PR49864 but also to PR49879. > > The fundamental problem in the first test case is that the > AVR target cannot perform > > (set (stack-pointer-rtx) > (plus (stack-pointer-rtx) (const_int large))) > > where "large" is in fact really quite small. This gets > dutifully reloaded to > > (set (reg temp) (stack-pointer-rtx)) > > (set (reg temp) (plus (reg temp) (const_int large))) > > (set (stack-pointer-rtx) (reg temp)) > > which, we have to admit, is perfectly reasonable. > > The code that we had in stack_adjust_offset would not > properly handle anything except immediate addends to > the stack pointer. Indeed, if it saw any other sort > of stack pointer adjustment, it gave up and assumed > that we'd reset the args_size level to 0. > > This exact problem hasn't shown up on other targets > either (1) because they ACCUMULATE_OUTGOING_ARGS, or > (2) while they may not be able to handle very large > addends to the stack pointer, we usually don't let > the pushed arguments grow to very large numbers; we > regularly reduce stack_pointer_delta. > > AVR is special in that it can't *really* perform any > direct addition to the stack pointer at all; "large" > is non-zero only because of a peephole pattern to use > pop insns into a scratch register for small adjustments. In CCing Denis. http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00075.html Is there a specific reason not to define ACCUMULATE_OUTGOING_ARGS on AVR? Addind/subtracting to SP is very expensive on AVR, even IRQs have to be disabled. Johann > I briefly considered adding an insn pattern that would > handle the entire mov/add/mov thing with a scratch, so > that we wouldn't have to do anything special. It seemed > relatively unlikely that any other port would be this > severely limited. > > However, then came a look at the second PR, where we > performed cross-jumping between two blocks with different > args_size values. > > For the specific case of the PR, this "merely" resulted > in wrong-debug, because we would in fact generate invalid > unwind info for one of the two paths. > > That said, I see no reason why this same cross-jump could > not occur with a real throw as opposed to an abort. And > in that case we would have wrong-code. > > I consulted the IRC oracle, and Ian didn't have any > objections in principal to a new reg-note. > > Comments? > > r~