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

[Hal Finkel]

----- Original Message -----
> From: "Sergey Dmitrouk" <sdmitrouk at accesssoftek.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Stephen Canon" <scanon at apple.com>, "Owen Anderson" <owen at apple.com>, "llvm-commits" <llvm-commits at cs.uiuc.edu>
> Sent: Friday, November 7, 2014 11:59:23 AM
> Subject: Re: [PATCH] Flag to enable IEEE-754 friendly FP optimizations
> 
> On Fri, Nov 07, 2014 at 09:15:34AM -0800, Hal Finkel wrote:
> > ----- Original Message -----
> > > From: "Sergey Dmitrouk" <sdmitrouk at accesssoftek.com>
> > > To: "Hal Finkel" <hfinkel at anl.gov>
> > > Cc: "Stephen Canon" <scanon at apple.com>, "Owen Anderson"
> > > <owen at apple.com>, "llvm-commits" <llvm-commits at cs.uiuc.edu>
> > > Sent: Friday, November 7, 2014 11:05:39 AM
> > > Subject: Re: [PATCH] Flag to enable IEEE-754 friendly FP
> > > optimizations
> > >
> > > 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.
> >
> > Unfortunately, I'm not sure this tells you anything. You need to
> > arrange for hosting, sinking, cse, etc. and it is hard to know
> > when this might occur. Why don't you post the patch you came up
> > with, and we'll see if we can construct some good test cases?
> 
> There wasn't much to show (I guess I lost it when repository got
> broken
> a bit), I just added cases for floating point instructions to
> may(ReadFrom/WriteTo)Memory methods that returned `true` to check if
> that affects anything.  If that's the correct thing to do in general,
> then I can go from here and look what else reorders that
> instructions,
> just wasn't sure I got that part right.

Yes, sounds about right.

 -Hal

> 
> --
> Sergey
> 
> >  -Hal
> >
> > >  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
> > >
> >
> > --
> > Hal Finkel
> > Assistant Computational Scientist
> > Leadership Computing Facility
> > Argonne National Laboratory
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory