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

Hal Finkel hfinkel at anl.gov
Fri Nov 7 09:15:34 PST 2014


----- 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?

 -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



More information about the llvm-commits mailing list