2.8 gcc on m68k
Jim Wilson (wilson@cygnus.com)
27 Feb 1998 1911:15:45 -0800
*** EOOH ***
Return-Path: <owner-crossgcc@cygnus.com>
>Received: from cygnus.com (runyon.cygnus.com [205.180.230.5])
by relay3.Austria.EU.net (8.8.8/8.8.8) with ESMTP id VAA15019
for <kaufmann@shraero.co.at>; Fri, 27 Feb 1998 21:09:32 +0100 (MET)
To: crossgcc@cygnus.com
Date: 27 Feb 1998 1911:15:45 -0800
From: wilson@cygnus.com (Jim Wilson)
Organization: Cygnus Solutions, CA
Path: cygnus.com!cygnus.com!not-for-mail
References: <9802262130.AA04917@visionpro.com>, <19980227044641.29015.qmail.cygnus.crossgcc@ragnarok.mlb.dmt.csiro.au>
Subject: Re: 2.8 gcc on m68k
Newsgroups: cygnus.crossgcc
Stamped: newsgate-cygnus
Sender: owner-crossgcc@cygnus.com
Precedence: bulk
Reply-To: wilson@cygnus.com (Jim Wilson)
Content-Type: text
Content-Length: 2551
In article <19980227044641.29015.qmail.cygnus.crossgcc@ragnarok.mlb.dmt.csiro.au>,
Robin Kirkham <Robin.Kirkham@mlb.dmt.csiro.au> wrote:
>
>Someone said (I've lost the original):
>
>> > I noticed that a particular set of operations was slower in the new 2.8
>> > compiler. Does anybody know what could be done to get back the 2.7.2.1
>> > speed, and still have the 68060 support?
>> >
>> > It appears that in general
>> > move rX(nn), rX(mm)
>> > has been replaced with
>> > move rX(nn), rY
>> > move rY, rX(mm)
>>
I have looked into this problem. It has nothing to do with the coldfire
support. It stems from a change to the machine independent part of the
compiler with how it handles some kinds of structures. As a result of this,
the compiler is now treating this particular structure as if it were a long
long instead of treating it as if it were an 8 byte block of memory. We end
up with worse code because of an inefficiency in the m68k long long support.
I am still thinking about how best to solve the problem, but I have a quick
hack to make it go away.
Thu Feb 26 15:20:16 1998 Jim Wilson <wilson@cygnus.com>
* m68k.md (movdi): Add o/o alternative.
Index: m68k.md
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/config/m68k/m68k.md,v
retrieving revision 1.5
diff -p -r1.5 m68k.md
*** m68k.md 1997/11/02 21:18:40 1.5
--- m68k.md 1998/02/26 23:20:08
***************
*** 1284,1291 ****
;; movdi can apply to fp regs in some cases
(define_insn ""
;; Let's see if it really still needs to handle fp regs, and, if so, why.
! [(set (match_operand:DI 0 "general_operand" "=rm,r,&ro<>,y,rm,!*x,!rm")
! (match_operand:DI 1 "general_operand" "rF,m,roi<>F,rmiF,y,rmF,*x"))]
; [(set (match_operand:DI 0 "general_operand" "=rm,&r,&ro<>,!&rm,!&f,y,rm,x,!x,!rm")
; (match_operand:DI 1 "general_operand" "r,m,roi<>,fF,rfmF,rmi,y,rm,x"))]
; [(set (match_operand:DI 0 "general_operand" "=rm,&rf,&ro<>,!&rm,!&f")
--- 1284,1291 ----
;; movdi can apply to fp regs in some cases
(define_insn ""
;; Let's see if it really still needs to handle fp regs, and, if so, why.
! [(set (match_operand:DI 0 "general_operand" "=rm,r,&ro<>,y,rm,!*x,!rm,o")
! (match_operand:DI 1 "general_operand" "rF,m,roi<>F,rmiF,y,rmF,*x,o"))]
; [(set (match_operand:DI 0 "general_operand" "=rm,&r,&ro<>,!&rm,!&f,y,rm,x,!x,!rm")
; (match_operand:DI 1 "general_operand" "r,m,roi<>,fF,rfmF,rmi,y,rm,x"))]
; [(set (match_operand:DI 0 "general_operand" "=rm,&rf,&ro<>,!&rm,!&f")