Re: Possible ANSI C Optimisation Done in Practice?

Ralph Corderoy <ralph@inputplus.demon.co.uk> wrote:
>
>> This is legal, if insane. What is worse, is that strlen is allowed
>> to set errno at whim (C99 7.5 paragraph 3), which makes the whole
>> function effectively unoptimisable.
>>
>> [It seems to me that since the compiler is allowed to treat strlen()
>> as a special case, part of the special case could include knowledge
>> that its version of strlen doesn't change errno. -John]
>
>Anyone help on the techniques used to determine modifying *t doesn't
>affect s?


Well, there are two levels to this. The first is standard alias
analysis, as described in books on optimisation theory. The second is
the detail of the specific language.


It is the latter that is so horrible in C. For more of the details
than any sane person wants to know, look at comp.std.c and/or join
your national language SC22/WG14 panel, and then ask about the
sequence point proposals, aliasing issues (including w.r.t. errno and
floating-point exceptions) and what objects are and when they overlap.


In practice, most C compiler writers do very little aggressive
optimisation. Those that do either take little notice of conformance
or spend a LOT of time investigating the area. The latter include the
major HPC vendors, of course.


In C99, there have been a LOT of changes to this area, most of which
are poorly understood and probably minor in effect. The introduction
of the concept of an effective type is perhaps the type specimen.


However, the restrict qualifier was introduced specifically for this
purpose, and is NOT minor. It is not easy to understand (except in
simple cases), but should make C as optimisable as Fortran.


C++ I don't know about.

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