Re: sincos CSE (was: quot/mod CSE...)

hbaker@netcom.com (Henry Baker) writes:
> 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 ??


Bill.Leonard@mail.hcsc.com wrote:
> But the optimizer is going to somehow mark expressions that it makes
> into CSEs, so that the code generator knows not to recompute it,
> right? So the code generator can conclude that unmarked expressions
> are not CSEs, so it doesn't need to compute both parts and can
> transform 'sinpart(sincos(x))' into just 'sin(x)'.


I guess I wasn't explicit enough about the rules. I was assuming that


1. The compiler does _not_ have access to the actual source code for
sincos(), sin(), cos().


2. The compiler knows that 'sinpart(sincos(x))' and 'sin(x)' are
'equivalent', in that they produce the same numerical answer.


3. The compiler has a crude performance model, in which in knows that
C(sin)+C(cos) > C(sincos) > C(sin), where C() means 'complexity of'.


4. We'll assume that 'sinpart()' is a trivial field extraction from a
record, or something else relatively simple, so that the compiler knows
very well how to handle it.


Clearly, if the compiler can actually 'see' the code for sincos and sin,
then it can estimate performance and/or do CSE on both expressions and
compute its own performance complexity model.


--
www/ftp directory:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html
--

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