Re: Possible ANSI C Optimisation Done in Practice?

nmm1@cus.cam.ac.uk (Nick Maclaren)
19 Dec 2001 23:58:55 -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)
[9 later articles]
| List of all articles for this month |
From: nmm1@cus.cam.ac.uk (Nick Maclaren)
Newsgroups: comp.compilers
Date: 19 Dec 2001 23:58:55 -0500
Organization: University of Cambridge, England
References: 01-12-050 01-12-073
Keywords: C, optimize, standards
Posted-Date: 19 Dec 2001 23:58:55 EST

Rodney M. Bates <rbates@southwind.net> wrote:
>Ralph Corderoy wrote:
>>
>> it seems to a group of us that the compiler could determine that
>> `strlen(s)' is invariant within the loop and hence just call strlen()
>> once. This is because, AIUI, the object pointed to by s cannot overlap
>> with that of tmp,
>
>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.
>
>Not surprisingly, ANSI C says the behaviour is undefined when
>you do this. (6.2.4(2,5)) A compliant compiler is under no obligation
>to tell you about it, at compile time or runtime. But it can still
>make optimizations which depend on non-overlap of the strings and
>claim to be compliant.


That is correct. But, in practice, that problem occurs WITHOUT
necessarily invoking undefined behaviour. As soon as you pass a
pointer to an object to an external function, you are aliasing that
object for the rest of its lifetime - and without any way of
cancelling the aliasing!


Theoretically, this applies even to errno. You are permitted to take
the address of errno and to pass it as an int or int array. Or,
actually, as any type with an alignment and size less than that of
int. C99 has locked out SOME cases by introducing the concept of
effective type, but nobody knows what that section of the standard
actually means. Seriously :-(


In the absence of restrict, the number of PRACTICAL cases where you
can assume no aliasing is so small that it gives no effective gain in
performance. You need some way for the programmer to say "Look, I am
behaving rationally here" - which is currently done by either
directives or 'dangerous' optimisation levels, and is in C99 as the
restrict qualifier.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: nmm1@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679


Post a followup to this message

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