This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: gcc-2.95.2 problem with target powerpc-eabi
- To: hirzel at indel dot ch
- Subject: Re: gcc-2.95.2 problem with target powerpc-eabi
- From: Michael Meissner <meissner at cygnus dot com>
- Date: Fri, 27 Oct 2000 10:45:52 -0400
- Cc: gcc-bugs at gcc dot gnu dot org
- References: <CGEDLEBEOPGKGDMFDPCCOEBOCBAA.hirzel@indel.ch>
On Fri, Oct 27, 2000 at 01:16:33PM +0200, Christoph Hirzel wrote:
> Hi
>
> There seems to be a problem in copying 64 Bit integers
> or structures with gcc-2.95.2 for target powerpc-eabi.
> If I compile the following code for a PowerPC 603
> (option -mcpu=603)
>
> unsigned long long u1;
> unsigned long long u2;
>
> void Test()
> {
> u1 = u2;
> }
>
> the compiler generates the following assembler code
>
> lis 11,u1@ha
> la 9,u1@l(11)
> lis 10,u2@ha
> la 11,u2@l(10)
> lfd 0,0(11)
> stfd 0,0(9)
>
> The compiler seems to optimize the copy by using load (lfd)
> and store (stfd) double float instructions.
>
> Now my question. How can I avoid this, without using the
> compiler option -msoft-float ?
> I think it should be possible if I make some adjustmenst
> in the rs6000.md /.c /.h files and then rebuild the compiler.
In general you can't. The compiler has to allow integers in fp registers in
order to allow the conversion of floating point to integer on the
power2/powerpc computers (the fctiwz instruction produces its result in a
floating point register). This is why the Linux kernel for instance compiles
with -msoft-float on the PowerPC, because it doesn't want the fpu modified
during interrupt processing to save fewer registers.
In terms of 'problems', the compiler should fold the two la's into the lfd and
stfd instructions like it does for loading 32-bit values into gprs.
--
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: meissner@redhat.com phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org fax: +1 978-692-4482