From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8689 invoked by alias); 16 Jun 2011 14:25:40 -0000 Received: (qmail 8645 invoked by uid 22791); 16 Jun 2011 14:25:39 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 16 Jun 2011 14:25:23 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p5GEPKMP017395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Jun 2011 10:25:21 -0400 Received: from anchor.twiddle.net (vpn-238-15.phx2.redhat.com [10.3.238.15]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p5GEPJa6000599; Thu, 16 Jun 2011 10:25:20 -0400 Message-ID: <4DFA124F.1090504@redhat.com> Date: Thu, 16 Jun 2011 14:36:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Thunderbird/3.1.10 MIME-Version: 1.0 To: Denis Chertykov CC: Georg-Johann Lay , gcc-patches@gcc.gnu.org, Anatoly Sokolov , "Eric B. Weddington" Subject: Re: [Patch, AVR]: Fix PR46779 References: <4DF0FAB5.6070704@gjlay.de> <4DF11D20.4030907@gjlay.de> <4DF1ED76.4030507@gjlay.de> <4DF650B7.3030705@gjlay.de> <4DF73490.2080709@gjlay.de> <4DF7D2B5.1090708@gjlay.de> <4DF8ED42.1030706@redhat.com> <4DF918A9.4070003@gjlay.de> <4DF92AEA.4000906@redhat.com> <4DF93B17.8020008@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 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-06/txt/msg01253.txt.bz2 On 06/16/2011 04:34 AM, Denis Chertykov wrote: > @rth (while you are diving into AVR microworld ;-) > May be you can give a suggestion to change the AVR abi. > I have tuned the abi for code size almost 13 years ago. > The register pressure to r18-r31 are very high. As far as I can see, the ABI is pretty good. There's nothing that I would say that should obviously be changed. I might totally drop support for DImode. Let "long long" map to SImode. If you want 64-bit data, you probably don't want to select an 8-bit microcontroller. That might take a bit of surgery on the way we currently build libgcc though. > I have a set of experiments with omitting the frame poiner and I found that > better to support fake addressing modes (infinite displacement for frame > pointer). The biggest problem that I see, from the 950612-1.c test case with the current handling of the "infinite displacement frame pointer", is that the adjustments to the frame pointer are never exposed as separate instructions, so there's never a chance to optimize them. So once you build a stack frame larger than 64 bytes, things get worse and worse. You wind up with code like subi r28,lo8(-133) sbci r29,hi8(-133) ld r18,Y subi r28,lo8(133) sbci r29,hi8(133) subi r28,lo8(-134) sbci r29,hi8(-134) ld r19,Y subi r28,lo8(134) sbci r29,hi8(134) where obviously the 4 middle instructions could be eliminated. If we came out of reload (or shortly thereafter via split) with these as separate patterns, we might be able to eliminate them via an existing optimization pass. OTOH, an existing pass might refuse to operate on the frame pointer because the frame pointer is usually Special. One could write an avr-specific pass for this: Scan the code for references to the frame pointer. Record the offsets of the uses. Compute a sliding 64-byte window that satisfies the maximum number of uses within the region. Insert adjustments to the frame pointer. Arrange for the dwarf2out routines to scan the whole function. (If alloca has been used, the frame pointer anchors the CFA, and the unwind info will need adjusting throughout the function. Otherwise gdb will fail entirely.) That last point probably depends on Bernd Schmidt's work in dwarf2out for shrink-wrapping... r~