Re: Why C is much slower than Fortran

In comp.arch John Hascall <john@iastate.edu> wrote:
> Erik Corry <erik@arbat.com> wrote:
>> Someone wrote:


>>> The only true solution for the alias problem is going to come from hardware:


>> I saw a rather nice solution on Usenet a few years ago.
>> All functions where optimisations are impossible due to C's liberal
>> aliasing rules are automatically compiled in two versions, one where
>> Fortran aliasing is assumed and one where it isn't. When you call the
>> function the compiler calls the right one according to whether it can
>> prove that arguments are unaliased. ...


> I wonder would it be sophisticated enough to tell the
> difference between something like this:


> a = malloc(100 * sizeof(int));
> b = malloc(100 * sizeof(int));
> ...
> func(a, b, 100);


> and with:


> b = malloc(150 * sizeof(int));
> a = b + 50;
> func(a, b, 100);


Doesn't look too difficult. A little data flow analysis on alias
classes, where every malloc returns a pointer from a new unique alias
class.


In the first case a and b are in different alias classes and you can
call the nonaliased version, in the second they are clearly in the
same alias class. Make the alias analysis fail safely to assuming
things are aliased ie if you con't know where the pointer is coming
from you have to assume it can be aliased with all chars and all
objects of the same type (as per ANSI C).


I don't have my copy of Muchnick at hand, but it doesn't look that
difficult. You mustn't forget aliases with globals and statics of
course.


One minor problem I can see is that malloc and new will have to be
special to the optimiser, so perhaps there needs to be a special way
of declaring malloc wrappers that lets the compiler know they too are
special in that they always return unaliased addresses. Since C has
no global analysis it can't figure that out itself, and a lot of large
projects have malloc wrappers.


--
Erik Corry erik@arbat.com Ceterum censeo, Microsoftem esse delendam!

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