Mail Archives: djgpp/2006/04/07/00:01:36
fOn 6 Apr 2006 14:16:07 -0700 in comp.os.msdos.djgpp, "Bob W"
<dontsend AT operamail DOT com> wrote:
>............
>
>> >Unfortunately, that detection is wrong for a function like clock(). I
>> >may be going out on a limb there, but this could require a change to
>> >the declaration of clock() and similar functions to forbid this kind
>> >of optimization.
>>
>> That kind of optimization is forbidden unless the (external) function
>> is declared with attributes pure or const (clock is not), or the
>> compiler can sufficiently determine the effect of the (internal)
>> function: even declaring the internal function static did not change
>> the code. If the compiler had inlined or reorganized the internal
>> function better, I could understand why it did what it did, but when
>> the workaround is declaring an auto variable (local) static, looks to
>> me like a bug: something is toggled the wrong way here.
>>
>
>
>
>
>After thinking it over and without thorough studies
>of C99 docs, I am still convinced that I have no
>right to blame gcc 410 for rearranging the code.
>
>But this does not necessarily stop me to moan
>about the fact that gcc 344 can get about the
>same performance on my computer without
>applying equally fancy tricks to the code.
>
>The reason why I think that I have to accept gcc's
>new features is due to the following reasons:
>
>
> -----------
> t0=clock();
> int ackret=Ack(3, n);
> t1=clock();
>
> printf("Ack(3,%d): %d\n", n, ackret);
> printf("Time1: %g secs\n", 1.0*(t1-t0)/CLOCKS_PER_SEC);
> -----------
>
>
>Ack() is no external function, so gcc has full control
>over code generation and can optimize it as much
>as it wants while obeying the only rule required:
>Get its return value ready when its is needed.
>This would be in the first printf() function.
>
>The clock() function is an ordinary external function,
>which has no special meaning to gcc other than that
>its return value is required in the second printf()
>function.
>
>There is no dependency between clock() and Ack(),
>so gcc has no reason to apply a specific sequence
>to code generation.
>
>It also makes no difference whether the clock()
>return values are assigned to locals or globals,
>because gcc can implicitly rule out that Ack()
>is accessing external variables.
>
>When using local variables (e.g. ackret) I have
>to be aware that the variable does not need to
>exist in memory. Therefore gcc is not required
>to assume that 'ackret' could be accessed by the
>clock() function.
>
>If I want to time Ack(), I have to get gcc to suspect
>that Ack's return value is needed earlier than in the
>printf() function. This would be before the 2nd
>clock() function is called.
>
>I can do this either by assigning its return value
>to a static, which in theory would be accessible
>by the subsequent clock() function.
>
>Alternatively I can accept a performance hit and
>create Ack() as an external function which cannot
>be ripped apart due to obvious reasons.
The generated code doesn't seem to differ much between the calls to
ack and clock, except for the arguments.
>Thoughts?
The compiler should support the timing of non-trivial functions even
(or especially) in optimized code.
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
Brian DOT Inglis AT CSi DOT com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply
- Raw text -