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

[Hal Finkel via llvm-commits]

----- Original Message -----
> From: "Sergey Dmitrouk" <sdmitrouk at accesssoftek.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Owen Anderson" <owen at apple.com>, "llvm-commits" <llvm-commits at lists.llvm.org>
> Sent: Monday, September 14, 2015 10:22:30 AM
> Subject: Re: [PATCH] Flag to enable IEEE-754 friendly FP optimizations
> 
> Hi Hal,
> 
> On Thu, Aug 27, 2015 at 07:47:17PM -0700, Hal Finkel wrote:
> > I think you might as well introduce new SDAG node types,
> > FADD_W_CHAIN,
> > etc. We're essentially not going to optimize them anyway, so I'm
> > not
> > worried about losing existing DAGCombine optimizations. The tricky
> > part
> > is that you need to instruction select these nodes into
> > instructions that
> > have side effects at the MI level, and this probably requires
> > modifying
> > the backends (it needs to have variants of the existing FP
> > instructions
> > marked with side effects). But this is probably unavoidable, and
> > luckily,
> > most of the changes seem largely rote.
> 
> I tried introducing new instruction, but got many instruction
> selection
> errors, which reminded me of issues people face when trying to
> disable
> DAGCombine for -O0 builds (can't be done easily because selection
> implicitly
> depends on DAGCombine).
> 
> So I tried to return to adding chain to FADD, please take a look at
> attached sample patch and say how bad does it look, there are changes
> to
> make FADD with chain work.  Side effects part is missing and it seems
> to require new instruction, but changes in the patch will be
> necessary
> anyway.  Don't go into much details, there are only three targets,
> and I
> basically would like to know how likely something like that to be
> accepted.

I don't think that you'll want to add a chain operand to the normal FADD instruction, because it will prevent CSEing and otherwise reordering those instructions (unless, perhaps, we just always set the chain operand to DAG.getEntryNode(), or UNDEF, when we don't need to preserve exception-based dependencies).

I think that you will need different instructions, because you need variants of the 'normal' floating-point instructions with the right set of register dependencies to accurately reflect the fact that they change the FP environment state, but you'll want to allow targets to transition incrementally to the new system. This could be done by, for example, having TableGen patterns, such as:

fadd - Matches, for example, and ISD::FADD

fadd_noexcept - Matches, ISD::FADD only with an UNDEF chain operand
fadd_except - Matches, ISD::FADD only with a non-undef chain operand

I think that something like this, provided it does not regress other targets/modes and enables incremental transitioning of the instruction definitions, would be accepted.

 -Hal

> 
> Thanks,
> Sergey
> 

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