Related articles |
---|
sincos CSE (was: quot/mod CSE...) hbaker@netcom.com (1996-02-09) |
Re: sincos CSE (was: quot/mod CSE...) jgj@ssd.hcsc.com (1996-02-09) |
Re: sincos CSE (was: quot/mod CSE...) bill@amber.ssd.hcsc.com (1996-02-13) |
Re: sincos CSE (was: quot/mod CSE...) hbaker@netcom.com (1996-02-14) |
Re: sincos CSE (was: quot/mod CSE...) richard@atheist.tamu.edu (1996-02-16) |
From: | jgj@ssd.hcsc.com (Jeff Jackson) |
Newsgroups: | comp.compilers |
Date: | 9 Feb 1996 17:18:27 -0500 |
Organization: | I would rather be windsurfing. |
References: | 96-02-064 |
Keywords: | optimize |
> I can understand how the above optimizations work, but I now don't
> understand how a sin(x) or cos(x) _by itself_ gets optimized. Perhaps
> the tree gets decorated with 'reference count' information saying how
> many nodes depend upon the sincos(x) node, so that if this refcount =
> 1, then the expression 'sinpart(sincos(x))' => 'sin(x)', as before ??
One approach is that the sincos(x) is treated as an operator that
generates a 16-byte value that has both sinpart and cospart. This
gets a cse created for it, so in this case, the actual code looks like:
temp=sincos(x)
...sinpart(temp)...
...cospart(temp)...
When such a CSE isn't created, then the sinpart(sincos(x)) gets folded
down to sin(x) and a regular sin operation takes place.
--
Jeffrey Glen Jackson
jgj@ssd.csd.harris.com
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.