Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!samsung!cs.utexas.edu!uunet!world!iecc!compilers-sender
From: jbc@hpcupt3.cup.hp.com (Jeff Caldwell)
Newsgroups: comp.compilers
Subject: Re: Optimizing IEEE Floating-Point Operations
Keywords: arithmetic, optimize
Message-ID: <91-06-031@comp.compilers>
Date: 19 Jun 91 17:22:27 GMT
References: <91-06-005@comp.compilers>
Sender: compilers-sender@iecc.cambridge.ma.us
Reply-To: jbc@hpcupt3.cup.hp.com (Jeff Caldwell)
Organization: Hewlett Packard, Cupertino
Lines: 29
Approved: compilers@iecc.cambridge.ma.us

> My own *personal* opinion is that this is a legal transformation if and
> only if the runtime system traps (and aborts) on generation of NaN's and
> Inf's.  

This sounds like a good idea but raises another question.  How about
a sequence such as:

    x = 0.0

    w = x * (y / z)

    where z ends up with the value of 0 at runtime.  

If this were allowed to become folded to a value of 0 at compile-time, the
calculation of y/z would never be performed.  Since y/z would have been
an invalid operation but has been removed, the runtime trap would never 
occur.

I feel the offering of an _option_ that allows the compiler to perform
transformations that may result in missing traps such as this is a
good approach.  The idea being that the user can stress test an application
until he is fairly sure it is robust enough to catch invalid operations
such as this before they occur.  Then he can use the option to build a
highly optimized production version of the application.

		-Jeff Caldwell | HP Calif. Lang. Lab
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.