Re: Hardware doing the work (Was Re: Why C is much slower than Fortran)

sjc@netcom.com (Steven Correll)
6 Jun 1999 22:58:39 -0400

          From comp.compilers

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)
| List of all articles for this month |
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


Post a followup to this message

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