From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12783 invoked by alias); 8 Jul 2004 20:07:29 -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 12747 invoked from network); 8 Jul 2004 20:07:27 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 8 Jul 2004 20:07:27 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i68K7Pe1013537; Thu, 8 Jul 2004 16:07:25 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i68K7P019391; Thu, 8 Jul 2004 16:07:25 -0400 Received: from free.redhat.lsd.ic.unicamp.br (vpn50-62.rdu.redhat.com [172.16.50.62]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id i68K7OFM005968; Thu, 8 Jul 2004 16:07:24 -0400 Received: from free.redhat.lsd.ic.unicamp.br (free.redhat.lsd.ic.unicamp.br [127.0.0.1]) by free.redhat.lsd.ic.unicamp.br (8.12.11/8.12.11) with ESMTP id i68K7NaH017921; Thu, 8 Jul 2004 17:07:23 -0300 Received: (from aoliva@localhost) by free.redhat.lsd.ic.unicamp.br (8.12.11/8.12.11/Submit) id i68K7NCQ017918; Thu, 8 Jul 2004 17:07:23 -0300 To: Richard Sandiford Cc: Kazu Hirata , gcc-patches@gcc.gnu.org Subject: Re: add h8sx support to h8300 References: <20040621.102356.74724063.kazu@cs.umass.edu> <87fz83f456.fsf@redhat.com> <87zn6aevpa.fsf@redhat.com> <873c42e8rb.fsf@redhat.com> From: Alexandre Oliva Organization: Red Hat Global Engineering Services Compiler Team Date: Thu, 08 Jul 2004 21:20:00 -0000 In-Reply-To: <873c42e8rb.fsf@redhat.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-07/txt/msg00834.txt.bz2 On Jul 8, 2004, Richard Sandiford wrote: > Alexandre Oliva writes: >>> I tried the attached, both with and without the h8300.md bit, >>> and it didn't make any difference to the results for this testcase. >>> Like you say, -O3 -fomit-frame-pointer fails either way. >> >> Right. But lower optimization levels failed before the patch, and >> passed with it. > But my point is that the testcase passes at the other optimisation > levels even if the patch I attached is applied. Anyhow, whether the testcase passes with your patch or not is not very relevant. Using !D at that point is wrong, for the reasons explained in the comments. ! prevents reload from even considering an alternative. So, given `d,!D', if it couldn't satisfy the constraint in local or global alloc, it will require r6 (or, worse, NO_REGS, if `d' happens to expand differently) during reload. NO_REGS will obviously be impossible to satisfy, and r6 may be impossible to satisfy if the frame pointer is found to be needed during reload (this happens in builtin-apply2). So we absolutely need another way to represent that. d,??D is probably not it, because reload will sometimes still choose the first alternative and die upon the impossibility of spilling r6 because the frame pointer became needed. I'm certainly open to change, but !D is not the way to go. It's wrong in theory, even if in practice it appears to work. I.e., as the compiler gets smarter, it will break. I could think of a few solutions that were probably worth trying, but I ran out of time before I could implement them: - introduce another virtual register, and use that as an alternative to `d', and then have a machine-dependent pass that `reloads' that into r6 as needed. - somehow give r6 a higher priority in being chosen to satisfy an `D' constraint, and force `d' to match before reload. - add another scratch register and hope it gets r6 if it's available at all, and use that to save/restore r6 otherwise - emit save r6, movmd with r6 referenced as an output hardware register, copy r6 elsewhere, restore r6 explicitly, and then optimize away the save and restore if it turns out that we got r6. Must somehow make sure reload doesn't emit output reloads that reference the modified r6. Yuck. Yeah, not an easy problem :-( -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}