similar to: [LLVMdev] Proposal for adding rounding variant of fpto?i instructions

On Jul 12, 2010, at 9:28 AM, Anton Lokhmotov wrote: > Hi Peter, > >> I would appreciate comments/feedback on this proposal to extend the >> fpto?i instructions to support rounding. > I think this might be useful. Actually, LLVM specifies that fpto?i convert > their operand into the nearest (rounding towards zero) signed integer value. > Do you have other rounding modes

Hi, I would appreciate comments/feedback on this proposal to extend the fpto?i instructions to support rounding. This is my first proposed significant extension to LLVM so I'd like to know if I'm completely off base here. First of all, I noticed the convert* intrinsics corresponding to the CONVERT_RNDSAT InstructionDAG. I propose not to build my work on top of these as they seem to be

On Mar 21, 2011, at 1:59 PM, Zhang, Chihong wrote: > Hi Chris, > > It is important for embedded/mobile computation to have efficient fp16 support, otherwise those users will suffer from the merging problem with their local LLVM with native fp16 type they add (locally). So we should either add full fp16 support as a basic floating point type or enhance the LLVM infrastructure to make

I couldn't find anything in the chron or timeDate packages, and a good search yielded rounding to the nearest half hour, which I don't want. The data: structure(list(Date = structure(c(1209625080, 1209641460, 1209652500, 1209676800, 1209682860, 1209692100, 1209706980, 1209722580, 1209726300, 1209739620, 1209762780, 1209765720, 1209770520, 1209791040, 1209812580, 1209829920,

Dear all, A hopefully simple question: how do I round a series of values (held in an object) to the nearest 5? I've checked out trunc, round, floor and ceiling, but these appear to be more tailored towards rounding decimal places. Thanks, Steve _________________________________________________________________ icons.

Hi, What is the rounding mode for the fptrunc instruction? Round to zero? Round to nearest? Or undefined? Regards, Jon

On Mar 21, 2011, at 3:44 AM, Anton Lokhmotov wrote: >> Adding half float to LLVM IR is *only* reasonable if you have hardware >> that supports half float, or if you want to add softfloat operations >> for these. > Yes, our graphics hardware natively supports some fp16 arithmetic > operations. Ok. >> Just like C compilers need to know sizeof(long), sizeof(void*) and

Hi, This is my proposal to add floating point accuracy support to LLVM. The intention is that the frontend may provide metadata to signal to the backend that it may select a less accurate (i.e. more efficient) instruction to perform a given operation. This is primarily a requirement of OpenCL, which specifies that certain floating point operations may be computed inaccurately. Comments

On Wed, Jul 24, 2013 at 4:03 AM, Jay Foad <jay.foad at gmail.com> wrote: > When the uitofp and sitofp instructions convert e.g. from i64 to > float, what rounding mode do they use? Answers in the form a patch to > LangRef.html would be great! The default rounding mode, just like every other floating-point operation. -Eli

When the uitofp and sitofp instructions convert e.g. from i64 to float, what rounding mode do they use? Answers in the form a patch to LangRef.html would be great! Thanks, Jay.

Hi all, I've got a matrix of fractional data that is all positive and greater than zero that I would like to "loosely" classify, for lack of a better word. It looks something like this : 1.07 1.11 1.27 1.59 0.97 0.76 2.23 0.98 0.71 0.88 1.19 1.02 What I'm looking for is a way to round these numbers to the nearest 0.25, i.e. the above matrix would be

I assume the FP_TO_SINT, FP_TO_UINT use C "round to 0" convention? What about values out of range? I think C99 standard says these are undefined. Thanks, Dan

Hi Chris, It is important for embedded/mobile computation to have efficient fp16 support, otherwise those users will suffer from the merging problem with their local LLVM with native fp16 type they add (locally). So we should either add full fp16 support as a basic floating point type or enhance the LLVM infrastructure to make floating point type as scalable as int type. -Chihong -----Original

Hi, Is there a recommended way to round to the nearest whole (x86 RC field of FPU control = 00) ? It appears an intentional truncation instruction is generated (if ms disassembly is correct): IRBuilder<>::CreateFPToSI %1 = fptosi double %0 to i64 00370025 fisttp qword ptr [esp] Thanks, Bob -------------- next part -------------- An HTML attachment was

It may be my lack of unerstanding, but round() seems to me to give inconsistent results when rounding 5s as in the following examples? > round(1.45, 1) [1] 1.4 # OK > round(2.45, 1) [1] 2.5 # shouldn't this be 2.4? > round(1.05, 1) [1] 1.1 # 1.0 ? and signif(): > signif(2.445, 3) [1] 2.44 # OK > signif(3.445, 3) [1]

POSIXct/lt supports fractional seconds (see Sub-second Accuracy section of man page), but there seem to be some inconsistencies in their handling. Converting to POSIXlt and back does not give back the same time for times before the origin: > t0 <- as.POSIXct('1934-01-05 23:59:59.00001') > t0 [1] "1934-01-06 00:00:00 EST" # rounding issue, see below >

Hi David, > On Nov 18, 2015, at 11:55 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > > Hi Quentin, > > On 18 Nov 2015, at 19:26, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> In the section “Goals", I defined (repeated for people that saw the talk) the goals for the Global ISel design. >> - Do you see

> On Sep 4, 2020, at 2:40 PM, Neil Nelson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> If fptosi takes 0.9 -> 0, then that is not 'rounding' in any sense I'm aware of (IEEE754 or otherwise). >> Rounding (in the IEE754 sense) determines how a number is converted when it is halfway between two >> candidate results. (see round(), ceil(),

If fptosi takes 0.9 -> 0, then that is not 'rounding' in any sense I'm aware of (IEEE754 or otherwise). Rounding (in the IEE754 sense) determines how a number is converted when it is halfway between two candidate results. (see round(), ceil(), floor()). fptosi seems to model the behavior of a C cast from float to int, which truncates the fractional bits (as in trunc()). Steve

The LLVM IR reference manual states, for fptosi: "The ‘fptosi’ instruction converts its floating-point <http://llvm.org/docs/LangRef.html#t-floating> operand into the nearest (rounding towards zero) signed integer value." I interpreted this to mean that it rounds: The nearest integer to 0.3 is 0. The nearest integer to 0.9 is 1. The nearest integer to 0.5 is either 0 or 1. And