|sincos CSE (was: quot/mod CSE...) firstname.lastname@example.org (1996-02-09)|
|Re: sincos CSE (was: quot/mod CSE...) email@example.com (1996-02-09)|
|Re: sincos CSE (was: quot/mod CSE...) firstname.lastname@example.org (1996-02-13)|
|Re: sincos CSE (was: quot/mod CSE...) email@example.com (1996-02-14)|
|Re: sincos CSE (was: quot/mod CSE...) firstname.lastname@example.org (1996-02-16)|
|From:||email@example.com (Richard Henderson)|
|Date:||16 Feb 1996 01:30:56 -0500|
|Organization:||Texas A&M University, College Station, TX|
Henry Baker <firstname.lastname@example.org> wrote:
>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 way to do this is to use feedback from data flow analysis.
As I related about divmod, GCC outputs both values into the RTL.
However, by the time it comes to emit code to generate the results, we
know whether or not the variable is live. If it isn't, don't generate
the code to compute the value.
>I can also understand why C systems would be loathe to perform this
>optimization, since the calling of sincos(x) instead of sin(x) might
>come as a shock to someone trying to debug a C program.
Given certain conditions, an ANSI C compiler is allowed to know about
ANSI Standard Library functions. I imagine that users would actually
be quite pleased to see, e.g., the "fsincos" insn emitted on their
Return to the
Search the comp.compilers archives again.