[PATCH] Flag to enable IEEE-754 friendly FP optimizations

[Sergey Dmitrouk]

On Fri, Nov 07, 2014 at 08:35:16AM -0800, Hal Finkel wrote:
> ----- Original Message -----
> > From: "Sergey Dmitrouk" <sdmitrouk at accesssoftek.com>
> > To: "llvm-commits" <llvm-commits at cs.uiuc.edu>
> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "Stephen Canon" <scanon at apple.com>, "Owen Anderson" <owen at apple.com>
> > Sent: Friday, November 7, 2014 10:29:12 AM
> > Subject: Re: [PATCH] Flag to enable IEEE-754 friendly FP optimizations
> >
> > Ping.
> >
> > > Hal, do I get it right that what you suggest can be implemented in
> > > Instruction::mayReadFromMemory() and
> > > Instruction::mayWriteToMemory() to
> > > get desired behaviour in wider range of usages?
> >
> > I guess no, because updating these two functions didn't change
> > anything.
>
> Exactly what did you check? The issue is reordering these instructions around function calls, etc., and we also might need changes to some other transformations that assume that no binary operators need to be checked for memory side effects.

That instructions (that correspond to "0.0/0.0" in my test) are not moved
after call to fetestexcept(), i.e. source code order is preserved.  The
effect I expected is that FP instructions will have the same relative
position with regard to function calls.

If some transformations doesn't check these flags, then results are fine
as many optimizations could effect this, I just thought they are handled
in a more generic way.  In this case I can find out what else reorders
instructions and how it desides which are safe to reorder.

Thanks,
Sergey

>  -Hal
>
> >
> > --
> > Sergey
> >
> > On Fri, Oct 31, 2014 at 06:19:40PM +0200, Sergey Dmitrouk wrote:
> > > Ping.  Rebased patches with a fix for a typo (in code, not in
> > > comments) are
> > > attached.
> > >
> > > Hal, do I get it right that what you suggest can be implemented in
> > > Instruction::mayReadFromMemory() and
> > > Instruction::mayWriteToMemory() to
> > > get desired behaviour in wider range of usages?
> > >
> > > Thanks,
> > > Sergey
> > >
> > > On Fri, Oct 24, 2014 at 09:24:48AM -0700, Stephen Canon wrote:
> > > >      On Oct 24, 2014, at 12:23 PM, Hal Finkel <hfinkel at anl.gov>
> > > >      wrote:
> > > >
> > > >      ----- Original Message -----
> > > >
> > > >        From: "Stephen Canon" <scanon at apple.com>
> > > >        To: "Hal Finkel" <hfinkel at anl.gov>
> > > >        Cc: "Sergey Dmitrouk" <sdmitrouk at accesssoftek.com>,
> > > >        "llvm-commits"
> > > >        <llvm-commits at cs.uiuc.edu>, "Owen Anderson"
> > > >        <owen at apple.com>
> > > >        Sent: Friday, October 24, 2014 11:13:10 AM
> > > >        Subject: Re: [PATCH] Flag to enable IEEE-754 friendly FP
> > > >        optimizations
> > > >
> > > >        As a necessary piece of building support for FENV_ACCESS,
> > > >        yes, I
> > > >        think this is worth pursuing.  Note, however, that
> > > >        actually
> > > >        providing full FENV_ACCESS support is likely to be a
> > > >        significant
> > > >        undertaking, and I expect that the pieces that go into it
> > > >        are
> > > >        basically useless until all of them are in place.
> > > >         Thata**s not to say
> > > >        that it isna**t worth doing, just that ita**s a big
> > > >        thankless job.
> > > >
> > > >      Steve, so long as you're willing to serve as the expert
> > > >      reviewer here,
> > > >      I'm happy to help move this forward as well. We should,
> > > >      however,
> > > >      probably have a plan for the rest of it. Maybe this is as
> > > >      simple as:
> > > >      when FP exceptions are enabled, we treat all FP operations
> > > >      as if they
> > > >      might write to memory (except that AA confirms that they
> > > >      don't actually
> > > >      alias with any address in particular, but we say nothing
> > > >      about function
> > > >      calls). What do you think?
> > > >
> > > >    From a numerical point of view, something along those lines
> > > >    could be
> > > >    workable, yes.
> > > >    a** Steve
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory