search for: roundingmode

Displaying 14 results from an estimated 14 matches for "roundingmode".

Did you mean: rounding_mode
2017 Nov 04
2
FW: clarification needed for the constrained fp implementation.
...gt; fesetround(OldRM); > > } else { > > Result = A/B; > > } > > return Result; > > } > > > ​... ​ > abridge > ​ ...​ > > > What I’m thinking is that we need something like this: > > void llvm.set.roundingmode(i32 mode) > > i32 lllvm.get.roundingmode() > > These would then get translated during instruction selection to > target-specific instructions, which is equivalent to what > fesetround() and fegetround() do. But I think it would also be > useful to have somet...
2008 Jan 23
4
[LLVMdev] Complex constant expressions?
...gt;> > > APFloat::convertToInteger does just this. Why can't you use it? > Well, I may be using it wrong. But looking at APFloat.h, I see four functions that purport to convert to integer: opStatus convertToInteger(integerPart *, unsigned int, bool, roundingMode) const; opStatus convertFromSignExtendedInteger(const integerPart *, unsigned int, bool, roundingMode); opStatus convertFromZeroExtendedInteger(const integerPart *, unsigned int, bool, roundingMode);...
2007 Aug 18
1
[LLVMdev] Soft floating point support
This patch supplies software IEEE floating point support. The comment from the patch reproduced below says all there is to say. This patch contains the prior "cleanup" patch; please don't apply that one. Please let me know of any bugs. It is tested reasonably well, but until I put together random tests it's hard to have 100% confidence. Neil. /* A self-contained host- and
2017 Nov 03
2
FW: clarification needed for the constrained fp implementation.
...ing mode because that would mean that the backend would need to generate instructions to get-set-restore the rounding mode around every operation in your function (unless the target supports explicit rounding mode operands). What I'm thinking is that we need something like this: void llvm.set.roundingmode(i32 mode) i32 lllvm.get.roundingmode() These would then get translated during instruction selection to target-specific instructions, which is equivalent to what fesetround() and fegetround() do. But I think it would also be useful to have something like this: void llvm.begin.local.roundingmode(i3...
2008 Jan 23
0
[LLVMdev] Complex constant expressions?
Talin wrote:- > Well, I may be using it wrong. But looking at APFloat.h, I see four > functions that purport to convert to integer: > > opStatus convertToInteger(integerPart *, unsigned int, bool, > roundingMode) const; > opStatus convertFromSignExtendedInteger(const integerPart *, > unsigned int, > bool, roundingMode); > opStatus convertFromZeroExtendedInteger(const integerPart *, > unsigned int, >...
2008 Jan 22
0
[LLVMdev] Complex constant expressions?
Talin wrote:- > On the other hand, writing an interpreter means duplicating a lot of > the functionality that's already in LLVM. For example, consider just > the problem of float to int conversions: > > char B[ (int)3.0 ]; > > Generating code for this is relatively simple; Converting > arbitrary-sized APFloats to arbitrary-sized APInts isn't quite as >
2020 Mar 02
2
Should rint and nearbyint be always constrained?
...exceptions or instructions that do not. The FP exceptions are assumed to be ignored. llvm.rint (delete, or identical semantics to llvm.nearbyint) llvm.experimental.constrained.nearbyint::semantics This function returns the same value as one of the IEEE 754-2019 roundToIntegral operations. If the roundingMode argument is fpround.dynamic, the behavior corresponds to whichever of the roundToIntegral operations matches the dynamic rounding mode when the operation is executed. The optimizer may not assume any rounding mode in this case, and backends must encode the operation in a way that uses the dynamic r...
2008 Jan 24
2
[LLVMdev] Complex constant expressions?
Neil Booth wrote: > Talin wrote:- > >> Well, I may be using it wrong. But looking at APFloat.h, I see four >> functions that purport to convert to integer: >> >> opStatus convertToInteger(integerPart *, unsigned int, bool, >> roundingMode) const; >> opStatus convertFromSignExtendedInteger(const integerPart *, >> unsigned int, >> bool, roundingMode); >> opStatus convertFromZeroExtendedInteger(const integerPart *, >> unsigned int, >>...
2020 Mar 03
2
Should rint and nearbyint be always constrained?
...mode? If so, explicitly defining what happens > when dynamic and "assumed" rounding mode don't match (see above) also > addresses this problem. Then the operations can be described like this: > > > If a rounding mode is assumed [RNE for non-constrained intrinsic or > roundingMode argument != fpround.dynamic] and the current dynamic rounding > mode differs from the assumed rounding mode, [pick one: behavior is > undefined / result is poison / ...]. Otherwise, X operation is performed > with the current dynamic rounding mode [which equals the statically assumed >...
2008 Jan 22
5
[LLVMdev] Complex constant expressions?
More questions on the best way to write a compiler using LLVM: Lets say I have a struct definition that looks like this: const int imageSize = 77; struct A { char B[align(imageSize)]; } ...where 'imageSize' is some small inline function that rounds up to a power of two or something. (A common requirement for textures on 3d graphics cards.) Now, clearly the compiler
2020 Mar 03
5
Should rint and nearbyint be always constrained?
...ppens >>> when dynamic and "assumed" rounding mode don't match (see above) also >>> addresses this problem. Then the operations can be described like this: >>> >>> > If a rounding mode is assumed [RNE for non-constrained intrinsic or >>> roundingMode argument != fpround.dynamic] and the current dynamic rounding >>> mode differs from the assumed rounding mode, [pick one: behavior is >>> undefined / result is poison / ...]. Otherwise, X operation is performed >>> with the current dynamic rounding mode [which equals the...
2020 Mar 02
2
Should rint and nearbyint be always constrained?
> > I'm not sure why this is an issue. Yes, these two intrinsics depend > on the current rounding mode according to the C standard, and yes, > LLVM in default mode assumes that the current rounding mode is the > default rounding mode. But the same holds true for many other > intrinsics and even the arithmetic IR operations like add. Any other intrinsic, like `floor`,
2007 Sep 22
0
[LLVMdev] APFloat storage complications
...---- next part -------------- Index: lib/Support/APFloat.cpp =================================================================== --- lib/Support/APFloat.cpp (revision 42219) +++ lib/Support/APFloat.cpp (working copy) @@ -1318,39 +1318,44 @@ APFloat::convert(const fltSemantics &toSemantics, roundingMode rounding_mode) { - unsigned int newPartCount; + lostFraction lostFraction; + unsigned int newPartCount, oldPartCount; opStatus fs; - + + lostFraction = lfExactlyZero; newPartCount = partCountForBits(toSemantics.precision + 1); + oldPartCount = partCount(); - /* If our new form is w...
2008 Feb 17
1
[LLVMdev] llvm 2.2 build problems
...ling APFloat.cpp for Release build APFloat.cpp: In constructor 'llvm::APFloat::APFloat(const llvm::fltSemantics&, const char*)': APFloat.cpp:680: warning: control may reach end of non-void function 'llvm::APFloat::opStatus llvm::APFloat::convertFromString(const char*, llvm::APFloat::roundingMode)' being inlined llvm[1]: Compiling APInt.cpp for Release build llvm[1]: Compiling Allocator.cpp for Release build llvm[1]: Compiling Annotation.cpp for Release build llvm[1]: Compiling CommandLine.cpp for Release build llvm[1]: Compiling ConstantRange.cpp for Release build llvm[1]: Compiling De...