Displaying 7 results from an estimated 7 matches for "noexcessfpprecision".
2012 Feb 08
6
[LLVMdev] Clarifying FMA-related TargetOptions
...n on the intended semantics for the various FP precision-related TargetOptions. I've summarized the three relevant ones below:
UnsafeFPMath - Defaults to off, enables "less precise" results than permitted by IEEE754. Comments specifically reference using hardware FSIN/FCOS on X86.
NoExcessFPPrecision - Defaults to off (i.e. excess precision allowed), enables higher-precision implementations than specified by IEEE754. Comments reference FMA-like operations, and X87 without rounding all over the place.
LessPreciseFPMADOption - Defaults to off, enables "less precise" FP multiply-add....
2012 Feb 08
0
[LLVMdev] Clarifying FMA-related TargetOptions
Hi Owen,
Having looked into this due to Clang failing PlumHall with it recently I can give an opinion...
I think !NoExcessFPPrecision covers FMA completely. There are indeed some algorithms which give incorrect results when FMA is enabled, examples being those that do floating point comparisons such as: a * b + c - d. If c == d, it is still possible for that result not to equal a*b, as "+c " will have been fused with th...
2012 Feb 08
1
[LLVMdev] Clarifying FMA-related TargetOptions
On Feb 8, 2012, at 10:44 AM, James Molloy wrote:
> Hi Owen,
>
> Having looked into this due to Clang failing PlumHall with it recently I can give an opinion...
>
> I think !NoExcessFPPrecision covers FMA completely. There are indeed some algorithms which give incorrect results when FMA is enabled, examples being those that do floating point comparisons such as: a * b + c - d. If c == d, it is still possible for that result not to equal a*b, as "+c " will have been fused with th...
2012 Feb 08
0
[LLVMdev] Clarifying FMA-related TargetOptions
...precision-related
> TargetOptions. I've summarized the three relevant ones below:
>
>
> UnsafeFPMath - Defaults to off, enables "less precise" results than
> permitted by IEEE754. Comments specifically reference using hardware
> FSIN/FCOS on X86.
>
>
> NoExcessFPPrecision - Defaults to off (i.e. excess precision allowed),
> enables higher-precision implementations than specified by IEEE754.
> Comments reference FMA-like operations, and X87 without rounding all
> over the place.
>
>
> LessPreciseFPMADOption - Defaults to off, enables "less p...
2009 May 21
0
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote:
> Can you explain why you chose the approach of using a new pass?
> I pictured removing LegalizeDAG's type legalization code would
> mostly consist of finding all the places that use TLI.getTypeAction
> and just deleting code for handling its Expand and Promote. Are you
> anticipating something more
2009 May 20
2
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
On May 20, 2009, at 1:34 PM, Eli Friedman wrote:
> On Wed, May 20, 2009 at 1:19 PM, Eli Friedman
> <eli.friedman at gmail.com> wrote:
>
>> Per subject, this patch adding an additional pass to handle vector
>>
>> operations; the idea is that this allows removing the code from
>>
>> LegalizeDAG that handles illegal types, which should be a significant
2009 May 21
2
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
...Result = DAG.getNode(Node->getOpcode(), dl, NVT, Result);
- break;
- case Expand:
- Result = ExpandIntToFP(Node->getOpcode() == ISD::SINT_TO_FP, NVT,
- Node->getOperand(0), dl);
- // Round if we cannot tolerate excess precision.
- if (NoExcessFPPrecision)
- Result = DAG.getNode(ISD::FP_ROUND_INREG, dl, NVT, Result,
- DAG.getValueType(VT));
- break;
- }
- break;
-
- case ISD::SIGN_EXTEND_INREG:
- Result = PromoteOp(Node->getOperand(0));
- Result = DAG.getNode(ISD::SIGN_EXTEND_INREG, dl, NVT, Re...