|Re: inlining + optimization = nuisance bugs email@example.com (Toon Moene) (1998-09-29)|
|Re: inlining + optimization = nuisance bugs firstname.lastname@example.org (1998-10-01)|
|Re: floating point, was inlining + optimization = nuisance bugs email@example.com (David Chase) (1998-10-04)|
|Re: floating point, was inlining + optimization = nuisance bugs firstname.lastname@example.org (Toon Moene) (1998-10-04)|
|Re: floating point, was inlining + optimization = nuisance bugs email@example.com (1998-10-05)|
|From:||Toon Moene <firstname.lastname@example.org>|
|Date:||4 Oct 1998 01:10:39 -0400|
|Organization:||Moene Computational Physics, Maartensdijk, The Netherlands|
email@example.com (Wclodius) wrote:
> Toon Moene <firstname.lastname@example.org> 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.
Well, now that you point it out to me, I should have added "IMDatedO"
to that phrase - all I know about compilers is written up in the 1977
edition of the Dragon book ;-) SSA has been discussed shortly on the
egcs list when it was very young (the list, that is), but it never got
Perhaps just storing both sides of an (in)equality operator in memory
before the comparison would already help.
Toon Moene (mailto:email@example.com)
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: mailto:firstname.lastname@example.org; egcs: mailto:email@example.com
Return to the
Search the comp.compilers archives again.