Displaying 3 results from an estimated 3 matches for "fpprecision".
2012 Oct 31
0
[LLVMdev] [RFC] Extend LLVM IR to express "fast-math" at a per-instruction level
...ready had extensive discussion with Chris on this. He has made it clear this *must* be implemented with subclass data bits, not with metadata.
More specifically, I reviewed the proposal and I agree with it's general design: I think it makes sense to use subclass data for these bits even though fpprecision doesn't. It follows the analogy of NSW/NUW bits which have worked well. I also think it makes a lot of sense to separate out the "relaxing FP math" part of the FP problem from orthogonal issues like modeling rounding modes, trapping operations (SNANs), etc.
That said, I agree that...
2012 Oct 30
2
[LLVMdev] [RFC] Extend LLVM IR to express "fast-math" at a per-instruction level
On Oct 30, 2012, at 1:46 AM, Duncan Sands <baldrick at free.fr> wrote:
> Hi Michael,
>
>> Flags
>> ---
>> no NaNs (N)
>> - ignore the existence of NaNs when convenient
>> no Infs (I)
>> - ignore the existence of Infs when convenient
>> no signed zeros (S)
>> - ignore the existence of negative zero when convenient
>
> while
2012 Nov 02
1
[LLVMdev] [RFC] Extend LLVM IR to express "fast-math" at a per-instruction level
...extensive discussion with Chris on this. He has made it clear this *must* be implemented with subclass data bits, not with metadata.
>
> More specifically, I reviewed the proposal and I agree with it's general design: I think it makes sense to use subclass data for these bits even though fpprecision doesn't. It follows the analogy of NSW/NUW bits which have worked well. I also think it makes a lot of sense to separate out the "relaxing FP math" part of the FP problem from orthogonal issues like modeling rounding modes, trapping operations (SNANs), etc.
>
> That said, I a...