similar to: [LLVMdev] round() vs. rint()/nearbyint() with fast-math

----- Original Message ----- > > On Fri, Jun 21, 2013 at 5:11 PM, Erik Schnetter < > schnetter at cct.lsu.edu > wrote: > > > > > > > On Fri, Jun 21, 2013 at 7:54 AM, David Tweed < david.tweed at arm.com > > wrote: > > > > > > > | LLVM does not currently have special lowering handling for round(), > | and >

On Fri, Jun 21, 2013 at 7:54 AM, David Tweed <david.tweed at arm.com> wrote: > | LLVM does not currently have special lowering handling for round(), and > I'll propose a patch to add that, but the larger question is this: should > fast-math change the tie-breaking behavior of > | rint/nearbyint/round, etc. and, if so, should we make a specific effort > to > have all

On Fri, Jun 21, 2013 at 5:11 PM, Erik Schnetter <schnetter at cct.lsu.edu>wrote: > On Fri, Jun 21, 2013 at 7:54 AM, David Tweed <david.tweed at arm.com> wrote: > >> | LLVM does not currently have special lowering handling for round(), and >> I'll propose a patch to add that, but the larger question is this: should >> fast-math change the tie-breaking

Hi everyone, According to the current design an intrinsic call that depends on current floating point environment (for example, rounding mode) or change it (for example by raising FP exceptions) is represented by constrained intrinsics. The latter have attached metadata that provide info about current FP environment and have attribute `IntrInaccessibleMemOnly` that helps keeping order of

Some clarification after getting feedback from Craig Topper…. It’s probably best to say in the documentation that the llvm.nearbyint and llvm.rint functions “assume the default rounding mode, roundToNearest”. This will allow the optimizer to transform them as if they were rounding to nearest without requiring backends to use an encoding that enforces roundToNearest as the rounding mode for these

> > The only issue I see is that since we also assume FP operations have no > side effects by default there is no difference between llvm.rint and > llvm.nearbyint. I wouldn’t have a problem with dropping llvm.rint > completely. The forthcoming C standard ( http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2454.pdf, 7.12.9.8) defines new function, `roundeven`, which implements

> > One concern with replacing llvm.rint and llvm.nearbyint with > llvm.roundeven makes it difficult to turn back into a libcall if the > backend doesn't have an instruction for it. You can't just call the > roundeven library function since that wouldn't exist in older libm > implementations. So ideally you would know which function was originally > used in the

> > 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`,

+cfe-dev as the discussion is now biased toward C standard. I'm not sure what problem you see here. In default mode, i.e. > when there is no "#pragma STDC FENV_ACCESS on" in effect, > then the compiler can always assume that the default rounding > mode is in effect. Well, if #pragma STDC FENV_ACCESS on is not in effect, that means > that the user has promised that at

Hello, I believe llvm.rint description in LangRef is not quite complete. Llvm seems to map math.h:rint() call to llvm.rint intrinsic, and the LangRef says that the result of llvm.rint matches the result of libm rint() call. Next, LangRef states that llvm.rint "returns the operand rounded to the nearest integer." Shouldn't the specification also say that "the actual rounding

Hi Cameron, Thank you for the comments, but I am confused even more now ☺ > llvm.rint won't honor the FPEnv in all cases. It falls under the default FPEnv The default FPEnv section specifies round-to-nearest rounding mode. In this case, how is it correct to map rint() user call to llvm.rint intrinsic call? If this is just a temporary inconsistency, and the long term solution is to map

I am coding with vorbis using mingw32 (g++ for win32 without the cygwin.dll dependency). mingw32's math library does not support rint and I can't find a replacement so I have tried the following: Use Cygwin to execute ./configure. Then: (1) "make" with Cygwin - ok. Cygwin supports rint. I encode my Aerosmith's "Get A Grip" .wav from the CD to .ogg with

At first glance, it looks like long double functions (such as fabsl and friends) are missing from your sysroot's <math.h>. Does your target support long double at all? -Dimitry > On 6 Feb 2018, at 09:51, Tobias Hieta via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > > I am trying to cross-compile libc++ from my x86_64 linux system to armv7hf. We have

Hello Dimitry and thanks for your answer. I am pretty sure it does indeed support long double. It's configured with vfpv3-d16 - but I noticed that c++config.h in gcc has _GLIBCXX__HAS_FABSL and friends are undefined. I think I need to look deeper at the configuration of our toolchain. long double support is required in libc++ then I gather? -- Tobias On Tue, Feb 6, 2018 at 11:47 AM,

Hello, I am trying to cross-compile libc++ from my x86_64 linux system to armv7hf. We have our own gcc compiler that we build with crosstools-ng (based on gcc 6.3.0) and I set my environment like this: CC=armv7a-plex-linux-gnueabihf-gcc CXX=armv7a-plex-linux-gnueabihf-g++ CFLAGS=-fPIC -DPIC -mfloat-abi=hard -march=armv7-a -Os -mfpu=vfpv3-d16 --sysroot=<path> CXXFLAGS=-fPIC -DPIC

Hello, I am trying to cross-compile libc++ from my x86_64 linux system to armv7hf. We have our own gcc compiler that we build with crosstools-ng (based on gcc 6.3.0) and I set my environment like this: CC=armv7a-plex-linux-gnueabihf-gcc CXX=armv7a-plex-linux-gnueabihf-g++ CFLAGS=-fPIC -DPIC -mfloat-abi=hard -march=armv7-a -Os -mfpu=vfpv3-d16 --sysroot=<path> CXXFLAGS=-fPIC -DPIC

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 > simplification.  There are still some issues with this patch, but does > the approach

It seems that fast-isel for intel does not handle strlen. It's a general problem in fast-isel . ~/llvmw/build/Deb~/llvmw/build/Debug+Asserts/bin/clang -O0 -mllvm -fast-isel-verbose -mllvm -fast-isel strlen1.c strlen1.c:12:3: warning: implicitly declaring library function 'printf' with type 'int (const char *, ...)' printf("%i\n", len); ^

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 simplification. There are still some issues with this patch, but does the approach look sane? -Eli -------------- next part -------------- Index: lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp

Dear Friends. I found something very puzzling with constOptim(). When I change the parameters for ConstrOptim, the error messages do not seem to be consistent with each other: > constrOptim(c(0.5,0.3,0.5), f=fit.error, gr=fit.error.grr, ui=ui,ci=ci) Error in constrOptim(c(0.5, 0.3, 0.5), f = fit.error, gr = fit.error.grr, : initial value not feasible > constrOptim(c(0.5,0.9,0.5),