Re: Possible ANSI C Optimisation Done in Practice?

ralph@inputplus.demon.co.uk (Ralph Corderoy)
20 Dec 2001 00:06:54 -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)
Re: Possible ANSI C Optimisation Done in Practice? ralph@inputplus.demon.co.uk (2001-12-22)
[7 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:54 -0500
Organization: InputPlus Ltd.
References: 01-12-050 01-12-073
Keywords: C, optimize
Posted-Date: 20 Dec 2001 00:06:54 EST

Hi Rodney,


> > #include <string.h>
> >
> > void foo(char *s)
> > {
> > char tmp[10];
> > char *t;
> > int i;
> >
> > t = tmp;
> > for (i = 0; i < strlen(s); i++) {
> > *t++ = s[i + 1];
> > }
> >
> > return;
> > }
>
> The following, sleazy program makes s overlap tmp:
>
> ...
>
> when compiled by gcc, x86, Linux. I would expect this behavior to be
> portable (if you will excuse this abuse of the word) across the
> majority of C implementations.


But if it wasn't, I'd be too ashamed to go forth and complain to the
compiler vendor :-)


> Not surprisingly, ANSI C says the behaviour is undefined when you do
> this. (6.2.4(2,5))


And my question was specifically about ANSI C, i.e. where the compiler
can assume that conforming code is being provided.


> IMHO, a reasonable criterion for optimizations is that they should
> not change the behavior of any program that compiles without error,
> but I believe all the standard requires is that it not change any
> behavior that is defined by the language.


And I'm quite happy with the standard and put my question in its
context.


> > and since t is initially assigned to tmp, and it isn't legal for t
> > to proceed past tmp + 10, assigning to *t can't be changing s.
>
> There is no way the rules of the language could prevent t from
> proceeding past tmp + 10, because the type system has already
> forgotten, by the time t = tmp; has been executed, that t points into
> array tmp.


You're mixing compile-time and run-time. I'm only interested in
compile-time. At that point, the compiler can tell that assigning to
*t won't modify s.


> Just call the original foo with a string longer than 10. Something
> will get stepped on


I have no interest in what may happen if the programmer breaks his
contract with the compiler expressed through the standard and his code.


Getting back on track, would static single assignment, SSA, be a method
that the compiler may use to track and determine that an assignment to
*t won't modify s? I've only come across the term from lurking on
comp.compilers.


And the other outstanding question: Is there a compiler in existence
that would recognise strlen(s) is invariant to the loop.


Cheers,
Ralph.


Post a followup to this message

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