Re: Possible ANSI C Optimisation Done in Practice?

ralph@inputplus.demon.co.uk (Ralph Corderoy)
20 Dec 2001 00:06:19 -0500

          From comp.compilers

Related articles
Possible ANSI C Optimisation Done in Practice? ralph@inputplus.demon.co.uk (2001-12-11)
Re: Possible ANSI C Optimisation Done in Practice? ralph@inputplus.demon.co.uk (Ralph Corderoy) (2001-12-15)
Re: Possible ANSI C Optimisation Done in Practice? rsherry8@home.com (Robert Sherry) (2001-12-15)
Re: Possible ANSI C Optimisation Done in Practice? rbates@southwind.net (Rodney M. Bates) (2001-12-15)
Re: Possible ANSI C Optimisation Done in Practice? nmm1@cus.cam.ac.uk (2001-12-19)
Re: Possible ANSI C Optimisation Done in Practice? ralph@inputplus.demon.co.uk (2001-12-20)
Re: Possible ANSI C Optimisation Done in Practice? ralph@inputplus.demon.co.uk (2001-12-20)
Re: Possible ANSI C Optimisation Done in Practice? ralph@inputplus.demon.co.uk (2001-12-20)
Re: Possible ANSI C Optimisation Done in Practice? RLWatkins@CompuServe.Com (R. L. Watkins) (2001-12-20)
Re: Possible ANSI C Optimisation Done in Practice? ralph@inputplus.demon.co.uk (2001-12-20)
Re: Possible ANSI C Optimisation Done in Practice? nmm1@cus.cam.ac.uk (2001-12-20)
Re: Possible ANSI C Optimisation Done in Practice? nmm1@cus.cam.ac.uk (2001-12-22)
[8 later articles]
| List of all articles for this month |

From: ralph@inputplus.demon.co.uk (Ralph Corderoy)
Newsgroups: comp.compilers
Date: 20 Dec 2001 00:06:19 -0500
Organization: InputPlus Ltd.
References: 01-12-050 01-12-068
Keywords: C, optimize
Posted-Date: 20 Dec 2001 00:06:19 EST

Hi Robert,


> For the case given, an optimizing compiler could perform the
> optimization of calling the strlen function only once. This
> optimization could be in done, with the following difficulties:
>
> 1) The compiler needs to know the strlen is a standard function and
> that its return value is based sole on its argument.


Straightforward. In <string.h> #define strlen(s) __strlen(s) as under
AIX.


> 2) The compiler also has to realize that the pointer s does not
> change.


There is no assignment to `char *s' provided as a parameter in the
whole routine, so it can do this.


> 3) The compiler has to recognize that the contents of the string
> pointed to by s does not change. To due this, it must recognize that
> t points to tmp and s does not point to s. This is not so easy to
> implement.


t is initialised to point to tmp and is only ever incremented. Under
ANSI C it's only valid to continue until t points to one char past the
end of tmp. tmp is a local variable to the routine, s is a parameter
passed in, so they can't overlap. Therefore writing to *t can't
affect s. Surely, this kind of reasoning is made use of in a
compiler, why else did ANSI `tighten' C with these kind of rules?


Cheers,
Ralph.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.