Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!spdcc!iecc!compilers-sender
From: meissner@osf.org
Newsgroups: comp.compilers
Subject: Re: C Compilers which use full 486 capabilities
Keywords: 486, C, optimize
Message-ID: <9103162305.AA28314@curley.osf.org>
Date: 16 Mar 91 23:05:01 GMT
References: <1991Mar15.173551.13702@rice.edu>
Sender: compilers-sender@iecc.cambridge.ma.us
Reply-To: meissner@osf.org
Organization: Compilers Central
Lines: 29
Approved: compilers@iecc.cambridge.ma.us
In-Reply-To: preston@ariel.rice.edu's message of 15 Mar 91 17:35:51 GMT

| [WRT the rather slow 486 XCHG instruction]
| Does anyone's compiler generate an exchange instruction?  I can visualize
| uses, but I'm not sure how I'd recognize it.  I can imagine peephole
| optimizers that could catch it, but generally, I dislike instructions with
| more than 1 result.
| 
| How would it integrate with register allocation?

When I started working on the 88k code generator for the GNU C
compiler at Data General, it supported the xmem and xmem.bu
instructions through peepholes.  The peephole checked for:

	reg1 <- memory1
	reg2 <- memory2
	memory1 <- reg2
	memory2 <- reg1

and converted it into the appropriate xmem instruction.  The code
wasn't safe, in that it should have made sure reg1 and reg2 were dead
after the peephole, but it could have been made safe with an
appropriate check.  This peephole did optimize the sort subtest in the
Stanford benchmarks.  I eventually removed it, when we ran the
compiler on an actual 88k, and compared the times to another compiler.
The sort benchmark was an anomaly, in that ran much slower for GCC
compared to the other compiler.  The reason of course is that xmem on
an 88k has to synchonize the machine before continuing.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.