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 ??


Naturally, the answer is, "it depends". :-)


That is, it depends on the compiler's intermediate form, how it does
CSE optimizations, and of course on what sinpart(x) and sincos(x)
generate.


> The problem is that -- unlike the quotmod case, where presumably there
> is no substantial additional cost in computing the mod when you only
> require the quotient (or vice versa) -- in the case of sincos(x), the
> amount of additional work to do cos(x) when you only require sin(x)
> may be substantial.


Yes, certainly that would be a concern.


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)'.


> Next question. Suppose now that a compiler is capable of doing the
> right thing for both cases -- i.e., when sin(x) is used by itself, or
> when sin(x) and cos(x) are used together. What happens if the user
> tries to 'optimize' the case sincos(x) himself? Has he actually made
> things worse for himself by introducing a new temporary variable and
> additional constraints, or is he no worse off than if it had simply
> used sin(x) and cos(x) and let the compiler do the work ??


That really would depend, both on the compiler and on what the user
did to "optimize" it. But in general, if the compiler's optimizer is
reasonably good, the user would have to transform the program in some
way such that it was not recognizably equivalent to its original form.
For instance, if the user has his own sincos function, its unlikely
that the optimizer can figure out what that function computes.


> (I can conceive of the programmer actually making things worse for
> himself if by adding additional variables and sequence points he
> inhibits other optimizations.)


Yep. Isn't programming fun? :-)


> The issue I'm trying to get at is whether there exist 'pessimizing'
> user-level optimizations, where a programmer can outsmart himself and
> make things much worse.


Absolutely! But again, it's very compiler-dependent.


> If there are, then it becomes even more important to advertise
> specifically what kinds of things the compiler already optimizes, so
> that the programmer is not tempted to second guess the compiler.


You have a point, but I suspect that most users would go ahead with
their own optimizations anyway. Many users are concerned with their
code being both portable *and* fast, so they would attempt to optimize
their code in ways that will be fast no matter whose compiler they
use. Of course, this information might help them avoid
pessimizations.


> Yes, we can find all these things out with exhausting tests of code
> generator behavior, but we then have to perform these tests all over
> again when the next release of the compiler comes out. This code
> generator testing is a _very_ tedious business.


It's very tedious to try to describe it as well. There are so many
possibilities, both in what the user can do and what the compiler can
do. I'm sure if there was enough clamor from compiler users, the
vendors would do it. Given that the vendors don't do it, I conclude
that not enough customers are interested in it to pay the vendors to
make the (huge) effort required.


--
Bill Leonard
Harris Computer Systems Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
Bill.Leonard@mail.hcsc.com
--

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