X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Trace-PostClient-IP: 68.147.232.190
From: Brian Inglis <Brian DOT Inglis AT SystematicSW DOT Invalid>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Sequence points, any?
Organization: Systematic Software
Message-ID: <msnb32lq8plrc62ip1vnon6bdum4g8jt7m@4ax.com>
References: <1144238453 DOT 674596 DOT 302360 AT z34g2000cwc DOT googlegroups DOT com> <200604051406 DOT k35E6iOx002313 AT envy DOT delorie DOT com> <1144285170 DOT 583086 DOT 24610 AT v46g2000cwv DOT googlegroups DOT com> <v1v832h6p1p2bn51mjva71bkg6aui4in9n AT 4ax DOT com> <49k31sFovesfU3 AT news DOT dfncis DOT de> <sofa3296m70vcfeo93regapfuis5qutsao AT 4ax DOT com> <1144358167 DOT 549081 DOT 289870 AT z34g2000cwc DOT googlegroups DOT com>
X-Newsreader: Forte Agent 1.93/32.576 English (American)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 98
Date: Fri, 07 Apr 2006 03:49:15 GMT
NNTP-Posting-Host: 64.59.135.176
X-Complaints-To: abuse AT shaw DOT ca
X-Trace: pd7tw2no 1144381755 64.59.135.176 (Thu, 06 Apr 2006 21:49:15 MDT)
NNTP-Posting-Date: Thu, 06 Apr 2006 21:49:15 MDT
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

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