Related articles |
---|
[25 earlier articles] |
Re: inlining + optimization = nuisance bugs ralph@inputplus.demon.co.uk (Ralph Corderoy) (1998-09-29) |
Re: inlining + optimization = nuisance bugs luddy@concmp.com (Luddy Harrison) (1998-09-29) |
Re: inlining + optimization = nuisance bugs tim@wagner.princeton.edu (1998-09-29) |
Re: inlining + optimization = nuisance bugs dmr@bell-labs.com (Dennis Ritchie) (1998-09-29) |
Re: inlining + optimization = nuisance bugs dmr@bell-labs.com (Dennis Ritchie) (1998-09-29) |
Re: inlining + optimization = nuisance bugs zalman@netcom.com (1998-10-01) |
Re: inlining + optimization = nuisance bugs wclodius@aol.com (1998-10-01) |
Re: inlining + optimization = nuisance bugs qjackson@wave.home.com (Quinn Tyler Jackson) (1998-10-04) |
Re: inlining + optimization = nuisance bugs luddy@concmp.com (Luddy Harrison) (1998-10-04) |
Re: floating point, was inlining + optimization = nuisance bugs toon@moene.indiv.nluug.nl (Toon Moene) (1998-10-04) |
From: | wclodius@aol.com (Wclodius) |
Newsgroups: | comp.compilers |
Date: | 1 Oct 1998 00:58:49 -0400 |
Organization: | AOL http://www.aol.com |
References: | 98-09-155 |
Keywords: | arithmetic, architecture |
Toon Moene <toon@moene.indiv.nluug.nl> wrote:
> Of course, the compiler _could_ remedy this by slowing down the
> whole computation such that every floating point intermediate was
> stored in memory (just singling out XNEW is too hard), <snip>
Is it too hard in general, or would it require a significant
restructuring of GCC in particular? I would expect this to be fairly
easy to do, for example, in a compiler that uses single structural
assignment for its intermediate representation.
William B. Clodius
Return to the
comp.compilers page.
Search the
comp.compilers archives again.