Re: Possible ANSI C Optimisation Done in Practice?

Ralph Corderoy <ralph@inputplus.demon.co.uk> wrote :
....
> 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?


AIUI the _reason_ for the pointer arithmetic limitations was so C
could be (and was) implemented on a wide variety of platforms, some
not using the flat-linear-address model where you can safely compute
(if not use) any pointer value. It represents the minimum necessary
to make the BCPL-derived array semantics work, without requiring
additional functionality that would constrain implementations without
being really useful.


The fact that this can sometimes assist in aliasing analysis is mostly
a happy accident. As already noted, C99 does so more generally and
formally with 'restrict'; by your logic, this wouldn't have been added
if it weren't needed, right?
--
- David.Thompson 1 now at worldnet.att.net
[The non-flat target that people cared about was the 286, of course. Ugh.
But I know several of the people who have been on the various C committees
and they were certainly aware that the more they could limit wacky aliasing,
the more optimization they could do. -John]

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