Related articles |
---|
Re: Why C is much slower than Fortran jhallen@world.std.com (1999-05-29) |
Hardware doing the work (Was Re: Why C is much slower than Fortran) creedy@mitretek.org (Chris Reedy) (1999-06-02) |
Re: Hardware doing the work (Was Re: Why C is much slower than Fortran jhallen@world.std.com (1999-06-03) |
Re: Hardware doing the work (Was Re: Why C is much slower than Fortran sjc@netcom.com (1999-06-06) |
Re: Hardware doing the work (Was Re: Why C is much slower than Fortran zalman@netcom.com (1999-06-06) |
From: | sjc@netcom.com (Steven Correll) |
Newsgroups: | comp.compilers,comp.arch |
Date: | 6 Jun 1999 22:58:39 -0400 |
Organization: | Netcom |
References: | <3710584B.1C0F05F5@hotmail.com> 99-05-142 99-06-021 99-06-024 |
Keywords: | C, Fortran, architecture |
Joseph H Allen <jhallen@world.std.com> wrote:
>I don't think the compiler has to do very much to support this. A C
>compiler has to unload registers around subroutine calls anyway...
>This should be a lot easier than trying to provide two versions of the
>code (one which assumes the alias and one which doesn't) plus code to
>test if the alias exists ahead of time, as someone else suggested.
The notion of emitting two copies of the same subroutine was motivated
by the situation where the aliased arguments are large arrays passed
by reference, where the subroutine in question contains an expensive
inner loop, and where a profitable optimization of that inner loop
assumes that aliasing does not occur. If the cost of copying the array
exceeds the benefit of the optimization, it makes sense to provide a
version of the subroutine without the optimization for use in the
aliased case.
--
Steven Correll == 1931 Palm Ave, San Mateo, CA 94403 == sjc@netcom.com
Return to the
comp.compilers page.
Search the
comp.compilers archives again.