Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| [12 earlier articles] |
| Re: Why C is much slower than Fortran sokal@holyrood.ed.ac.uk (Daniel Barker) (1999-06-02) |
| Re: Why C is much slower than Fortran djb@koobera.math.uic.edu (1999-06-02) |
| Re: Why C is much slower than Fortran Peter.Mayne@compaq.com (Peter Mayne) (1999-06-03) |
| Re: Why C is much slower than Fortran lindahl@pbm.com (1999-06-06) |
| Re: Why C is much slower than Fortran john@iastate.edu (1999-06-12) |
| Re: Why C is much slower than Fortran erik@arbat.com (Erik Corry) (1999-06-14) |
| Re: Why C is much slower than Fortran jeff@jeff-jackson.com (Jeffrey Glen Jackson) (1999-06-19) |
| From: | "Jeffrey Glen Jackson" <jeff@jeff-jackson.com> |
| Newsgroups: | comp.compilers |
| Date: | 19 Jun 1999 17:53:20 -0400 |
| Organization: | MindSpring Enterprises |
| References: | <3710584B.1C0F05F5@hotmail.com> 99-05-057 99-05-142 99-06-005 99-06-053 99-06-062 |
| Keywords: | C, optimize |
The most recent release of C and C++ from concurrent computer
corporation does just this: there are two #pragmas:
returns_new_object and returns_new_zeroed_object so
that memory allocating routines can be declared to the
optimizer.
--
> 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.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.