Re: C Compilers which use full 486 capabilities

meissner@osf.org
Sat, 16 Mar 91 18:05:01 -0500

          From comp.compilers

Related articles
C Compilers which use full 486 capabilities mcarrick@gara.une.oz.au (Mick Carrick) (1991-03-13)
Re: C Compilers which use full 486 capabilities mason+@transarc.com (1991-03-15)
Re: C Compilers which use full 486 capabilities preston@ariel.rice.edu (1991-03-15)
Re: C Compilers which use full 486 capabilities meissner@osf.org (1991-03-16)
Re: C Compilers which use full 486 capabilities rex@aussie.COM (1991-03-17)
Re: C Compilers which use full 486 capabilities pardo@cs.washington.edu (1991-03-18)
Re: C Compilers which use full 486 capabilities preston@ariel.rice.edu (1991-03-19)
| List of all articles for this month |

Newsgroups: comp.compilers
From: meissner@osf.org
In-Reply-To: preston@ariel.rice.edu's message of 15 Mar 91 17:35:51 GMT
Keywords: 486, C, optimize
Organization: Compilers Central
References: <1991Mar15.173551.13702@rice.edu>
Date: Sat, 16 Mar 91 18:05:01 -0500

| [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.
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.