Re: Short-circuiting the optimizer
- From: "toby" <toby@xxxxxxxxxxxxxxxxxxx>
- Date: 20 Jun 2006 16:32:22 -0700
Steve Richfie1d wrote:
Toby,
The easiest way is to write a trivial function of two arguments, that
simply returns the first argument and completely ignores the second
argument. Everywhere you use this function, use a DIFFERENT second
argument value. You can define the second argument as being a string,
and then document your code by putting different comments in as the
second arguments.
Steve, this breaks down immediately if the compiler simply inlines short
functions:
I don't think that many compilers do this and haven't seen this myself,
especially since doing this can produce different results, e.g. where an
argument containing a function call with side effects is used several
times within a function.
That sounds like a macro, which is not related to inlining in C
compilers, at least. Inlined functions would evaluate arguments only
once, and would be semantically equivalent to the subroutine call. And
this happens automatically (even by default) in many environments.
I suppose that if in doubt, that you could simply guarantee destructive
side effects on such optimization so that it wouldn't be performed, e.g.
by creating a Side function that simply adds its argument to a global
variable as well as returning its argument, and then making some other
use of the first argument in the Use function I advanced, like adding it
to the same global variable. Since the number of times that the argument
would be added to the global variable would be dependent on whether the
function was inlined, the compiler would then be forced not to inline
the function to work as the specs say.
Right; and if it *isn't* inlining, it probably can't know that the
function doesn't have side-effects, and therefore a simple function
call suffices to prevent optimisation (no need for second argument).
The problem here is that many/most languages presume that any function
called with the same arguments returns the same results.
That assumption simply cannot be made unless the compiler has verified,
or has been told, there are no side effects. Repeating myself, the
second argument serves no purpose *if* the compiler is doing its own
analysis.
Some
programmers call the same transcendental function with the same argument
many times within a basic block, so compilers seek to evaluate the
function just once to make this sort of sloppy programming run faster.
Assuming the compiler has been "told" some functions are idempotent.
This might make sense for some libraries. In the absence of such an
assertion, is it not common sense that it should assume otherwise?
Hence, while the second argument isn't needed to force a call to the
function, without it, the SECOND call to the function may be optimized
out to utilize the results of the first call, which would be OK if
subsequent optimization didn't then see the comparison of equals and
optimize out both calls, replacing the whole thing with just a True,
which would then be optimized out to nothing.
Steve Richfie1d
.
- References:
- Testing for IEEE infinity and NaN?
- From: Raymond Toy
- Re: Testing for IEEE infinity and NaN?
- From: bert
- Re: Testing for IEEE infinity and NaN?
- From: Raymond Toy
- Short-circuiting the optimizer
- From: Steve Richfie1d
- Re: Short-circuiting the optimizer
- From: Terje Mathisen
- Re: Short-circuiting the optimizer
- From: toby
- Re: Short-circuiting the optimizer
- From: Steve Richfie1d
- Testing for IEEE infinity and NaN?
- Prev by Date: Re: Testing for IEEE infinity and NaN?
- Next by Date: C99 Annex G :-(
- Previous by thread: Re: Short-circuiting the optimizer
- Next by thread: Re: Short-circuiting the optimizer
- Index(es):
Relevant Pages
|
|
