Re: why not consfold sin(const)

[Robert Dewar <dewar at gnat dot com>]

Luchezar Belev wrote:

> Here is one example of how this could be useful:
> Imagine you have some defined floating point const MY_CONST in your program and you use it in
> various floating point expressions in different ways. Say somewhere you use the expression
> x+MY_CONST, somewhere else you use the expression log(x)/log(MY_CONST), and somewhere else
> exp(2-x*(MY_CONST + sqrt(MY_CONST))) and so on.

Yes, indeed, that's the most likely scenario
> Of course you could define different consts for 1/log(MY_CONST) and MY_CONST+sqrt(MY_CONST), but
> that's not very beautifuf, especially if you would like to change the value of MY_CONST from time
> to time - then you would have to recalculate all of it's derivated consts too.

Well not really, you would simply define these as constants with the given
initial values. There obviously is no significant overhead in computing
these guys once.

But the stylistic issue here is not so clear.

I think everyone would agree that you do not want to see

   sin (0.362789)

appearing in other than a constant declaration, but

   sin (Take_Off_Angle)

where Take_Off_Angle is a constant, seems reasonable.

So that indeed is an argument in favor of this optimization.
Of course in practice a constant like this will often be pulled
out of loops, CSE'ed etc, so the impact may be smaller than
expected.

Generally speaking in compiler-development-land, far too much effort
goes into optimizations that have no measureable significant value.

So the best argument for a given optimization is to show a real program
where the optimization would make a real difference.

I remember from SPITBOL times that many people would write to us
suggesting an optimization. We then imposed a rule that we would
only publish such suggestions in the newsletter if they were
accompanied by a sample program where the optimization would
speed things up at least a few percent. The flow of suggestions
completely dried up :-)