X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
From: "Bob W" <dontsend AT operamail DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Sequence points, any?
Date: 6 Apr 2006 14:16:07 -0700
Organization: http://groups.google.com
Lines: 85
Message-ID: <1144358167.549081.289870@z34g2000cwc.googlegroups.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>
NNTP-Posting-Host: 84.102.38.245
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: posting.google.com 1144358173 16192 127.0.0.1 (6 Apr 2006 21:16:13 GMT)
X-Complaints-To: groups-abuse AT google DOT com
NNTP-Posting-Date: Thu, 6 Apr 2006 21:16:13 +0000 (UTC)
User-Agent: G2/0.2
X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727),gzip(gfe),gzip(gfe)
Complaints-To: groups-abuse AT google DOT com
Injection-Info: z34g2000cwc.googlegroups.com; posting-host=84.102.38.245;
   posting-account=CXf2IQ0AAADhHwR4LIBYSPHMQKV3cPd3
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

............

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


Thoughts?