From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20951 invoked by alias); 1 Jul 2009 01:44:34 -0000 Received: (qmail 20941 invoked by uid 22791); 1 Jul 2009 01:44:33 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 01 Jul 2009 01:44:24 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n611iM3L031224; Tue, 30 Jun 2009 21:44:22 -0400 Received: from omfg.slc.redhat.com (vpn-225-40.phx2.redhat.com [10.3.225.40]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n611iKdh008956; Tue, 30 Jun 2009 21:44:21 -0400 Message-ID: <4A4ABF9D.2040609@redhat.com> Date: Wed, 01 Jul 2009 01:44:00 -0000 From: Jeff Law User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: daniel tian CC: gcc@gcc.gnu.org Subject: Re: Address mode offset spill References: <121fadb80906140733g6b1eec5eg4ea945867f4affb7@mail.gmail.com> <4A36B7A3.5040403@redhat.com> <4A36C7CA.7070101@redhat.com> <121fadb80906160325q2425b052ib87dadcd66ca6820@mail.gmail.com> <4A43DF1E.80302@redhat.com> <121fadb80906252028s25ac7b7am16d3d0f8490677b9@mail.gmail.com> In-Reply-To: <121fadb80906252028s25ac7b7am16d3d0f8490677b9@mail.gmail.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-07/txt/msg00000.txt.bz2 daniel tian wrote: > Only do using R0. Like the following with loading 0x12345: > > MOVI 0x2345 -L //To load the lower 16bit data > MOVI 0x1 -H //Load the up 16bit data > OK. So it appears to me like R0 needs to be an intermediate secondary reload for register anytime you have a load of a large constant integer into any class other than R0_REGS (I'm assuming you've put R0 into its own class, which would normally be named R0_REGS). > Now my approach is to define the Macro PREFERRED_RELOAD_CLASS(X, > CLASS), and make sure if the X is const int and larger than 512, it > will return the R0_REG register class. > That will certainly help, but won't be sufficient to handle all the cases. You still need to define your secondary reload class macros/functions. > PS: I think that if I don't define the macro LEGITIMIZE_RELOAD_ADDRESS > which will push reload the larger const int, the > PREFERRED_RELOAD_CLASS won't be called. is it right? > I don't know offhand. If I remember correctly, PREFERRED_RELOAD_CLASS is another method for optimizing the code -- which means your port should work with or without PREFERRED_RELOAD_CLASS defined. It also means there's no guarantee PREFERRED_RELOAD_CLASS will be honored in all cases. Jeff