search for: fe_inexact

...und(FE_DOWNWARD); printf("foo downward: %f\n", rint(0.5)); fesetround(FE_UPWARD); printf("foo upward: %f\n", rint(0.5)); } If compiled with optimization, only one call to rint() is made and the result is reused. void bar(double a, double b) { feclearexcept(FE_INEXACT); a / b; printf("bar %f / %f is %sexact\n", a, b, fetestexcept(FE_INEXACT)? "in": ""); } The compiler omits the divide as the result is unused. And so on. Presumably this has never worked? And perhaps LLVM is no worse than other compilers in this regard...

Changing the list from cfe-dev to llvm-dev > On 20 Apr 2017, at 4:52 AM, Michael Clark <michaeljclark at mac.com> wrote: > > I’m getting close. I think it may be an issue with an individual intrinsic. I’m looking for the X86 lowering of Instruction::FPToUI. > > I found a comment around the rationale for using a conditional move versus a branch. I believe the predicate logic

...ee if it is faster. -Andy From: Michael Clark [mailto:michaeljclark at mac.com] Sent: Thursday, April 20, 2017 4:02 PM To: Kaylor, Andrew <andrew.kaylor at intel.com> Cc: Flamedoge <code.kchoi at gmail.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [cfe-dev] FE_INEXACT being set for an exact conversion from float to unsigned long long On 21 Apr 2017, at 8:50 AM, Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>> wrote: > This seems like it was done for perf reason (mispredict). Conditional-to-cmov transformation shoul...

...nding patch addresses. -Andy From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Flamedoge via llvm-dev Sent: Wednesday, April 19, 2017 10:14 AM To: Michael Clark <michaeljclark at mac.com> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [cfe-dev] FE_INEXACT being set for an exact conversion from float to unsigned long long > Are we better off using branches instead of cmove to implement FP to unsigned i64? This seems like it was done for perf reason (mispredict). Conditional-to-cmov transformation should keep from introducing additional observabl...

...way I understand it, but. On some cross compilation platforms this might not be always true. In case of Hexagon for example our FP math handling is apparently more precise then "stock" one on x86 host. Specific (but not the best) example would be computing sqrtf(1.000001). Result is 1 + FE_INEXACT set. My current linux x86 host fails the inexact part. resulting in wrong code emitted. Once again, my question is not about this specific example, but rather about the assumption of identical behavior of completely different systems. What if my target's "objective" is to exceed...

...king for unistd.h - found -- Looking for valgrind/valgrind.h -- Looking for valgrind/valgrind.h- not found -- Looking for zlib.h -- Looking for zlib.h - found -- Looking for fenv.h -- Looking for fenv.h - found -- Looking for FE_ALL_EXCEPT -- Looking for FE_ALL_EXCEPT -found -- Looking for FE_INEXACT -- Looking for FE_INEXACT - found -- Looking for mach/mach.h -- Looking for mach/mach.h - found -- Looking for histedit.h -- Looking for histedit.h - found -- Looking forCrashReporterClient.h -- Looking forCrashReporterClient.h - not found -- Performing TestHAVE_CRASHREPORTER_INFO -- Perfo...

...erstand it, > but… On some cross compilation platforms this might not be always true. In > case of Hexagon for example our FP math handling is apparently more precise > then “stock” one on x86 host. Specific (but not the best) example would be > computing sqrtf(1.000001). Result is 1 + FE_INEXACT set. My current linux > x86 host fails the inexact part… resulting in wrong code emitted.**** > > ** ** > > Once again, my question is not about this specific example, but rather > about the assumption of identical behavior of completely different systems. > What if my target...

...ing for valgrind/valgrind.h > -- Looking for valgrind/valgrind.h - not found > -- Looking for zlib.h > -- Looking for zlib.h - found > -- Looking for fenv.h > -- Looking for fenv.h - found > -- Looking for FE_ALL_EXCEPT > -- Looking for FE_ALL_EXCEPT - found > -- Looking for FE_INEXACT > -- Looking for FE_INEXACT - found > -- Looking for mach/mach.h > -- Looking for mach/mach.h - found > -- Looking for mach-o/dyld.h > -- Looking for mach-o/dyld.h - found > -- Looking for pthread_create in pthread > -- Looking for pthread_create in pthread - found > -- Look...

...h -- Looking for utime.h - found -- Looking for valgrind/valgrind.h -- Looking for valgrind/valgrind.h - not found -- Looking for zlib.h -- Looking for zlib.h - found -- Looking for fenv.h -- Looking for fenv.h - found -- Looking for FE_ALL_EXCEPT -- Looking for FE_ALL_EXCEPT - found -- Looking for FE_INEXACT -- Looking for FE_INEXACT - found -- Looking for mach/mach.h -- Looking for mach/mach.h - found -- Looking for mach-o/dyld.h -- Looking for mach-o/dyld.h - found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Looking for pthread_getspecific in pthread -...

On Wed, Apr 24, 2013 at 5:26 PM, Chris Lattner <clattner at apple.com> wrote: > On Apr 24, 2013, at 5:01 PM, Dan Gohman <dan433584 at gmail.com> wrote: > > In the spirit of the (long-term) intent to migrate away from the > SelectionDAG framework, it is desirable to implement legalization passes as > discrete passes. Attached is a patch which implements the beginning of

...Looking for valgrind/valgrind.h - not found > > -- Looking for zlib.h > > -- Looking for zlib.h - found > > -- Looking for fenv.h > > -- Looking for fenv.h - found > > -- Looking for FE_ALL_EXCEPT > > -- Looking for FE_ALL_EXCEPT - found > > -- Looking for FE_INEXACT > > -- Looking for FE_INEXACT - found > > -- Looking for mach/mach.h > > -- Looking for mach/mach.h - found > > -- Looking for mach-o/dyld.h > > -- Looking for mach-o/dyld.h - found > > -- Looking for pthread_create in pthread > > -- Looking for pthread_cre...

...way I understand it, but. On some cross compilation platforms this might not be always true. In case of Hexagon for example our FP math handling is apparently more precise then "stock" one on x86 host. Specific (but not the best) example would be computing sqrtf(1.000001). Result is 1 + FE_INEXACT set. My current linux x86 host fails the inexact part. resulting in wrong code emitted. Once again, my question is not about this specific example, but rather about the assumption of identical behavior of completely different systems. What if my target's "objective" is to exceed...

...ime.h -- Looking for utime.h - found -- Looking for valgrind/valgrind.h -- Looking for valgrind/valgrind.h - found -- Looking for zlib.h -- Looking for zlib.h - found -- Looking for fenv.h -- Looking for fenv.h - found -- Looking for FE_ALL_EXCEPT -- Looking for FE_ALL_EXCEPT - found -- Looking for FE_INEXACT -- Looking for FE_INEXACT - found -- Looking for mach/mach.h -- Looking for mach/mach.h - not found -- Looking for mach-o/dyld.h -- Looking for mach-o/dyld.h - not found -- Looking for histedit.h -- Looking for histedit.h - found -- Performing Test HAVE_CXXABI_H -- Performing Test HAVE_CXXABI_H - S...

This file is for configure+make build, not CMake, so I'm not sure why it's being included into your build (these failures aren't reproducible for me). Can you please list the exact steps you're doing to build LLVM with CMake and make sure you don't have additional CFLAGS (LDFLAGS etc) defined? On Mon, Nov 11, 2013 at 6:16 PM, Jack Howarth <howarth at bromo.med.uc.edu>

Hallo all, I was trying to Build LLVM with the cmake option LLVM_ENABLE_MODULES just out of curiosity. I used the RELEASE_400/final tag. It didn't work as I almost expected. So I'm wondering if the modulemaps aren't maintained anymore? If they aren't maintained anymore, why aren't they removed and that cmake option also removed?

Hi, I'm trying to do a build and install on Windows 10 with Visual Studio 2015 Community Edition for the X86 and ARM targets, from the current release_40 branch. While compilation completes without error, the INSTALL target fails with the following error: 54> CMake Error at projects/compiler-rt/lib/builtins/cmake_install.cmake:34 (file): 54> file INSTALL cannot find 54>

...Looking for unistd.h - found -- Looking for valgrind/valgrind.h -- Looking for valgrind/valgrind.h - not found -- Looking for zlib.h -- Looking for zlib.h - not found -- Looking for fenv.h -- Looking for fenv.h - found -- Looking for FE_ALL_EXCEPT -- Looking for FE_ALL_EXCEPT - found -- Looking for FE_INEXACT -- Looking for FE_INEXACT - found -- Looking for mach/mach.h -- Looking for mach/mach.h - not found -- Looking for histedit.h -- Looking for histedit.h - not found -- Looking for CrashReporterClient.h -- Looking for CrashReporterClient.h - not found -- Looking for linux/magic.h -- Looking for linux...

...Looking for unistd.h - found -- Looking for valgrind/valgrind.h -- Looking for valgrind/valgrind.h - not found -- Looking for zlib.h -- Looking for zlib.h - not found -- Looking for fenv.h -- Looking for fenv.h - found -- Looking for FE_ALL_EXCEPT -- Looking for FE_ALL_EXCEPT - found -- Looking for FE_INEXACT -- Looking for FE_INEXACT - found -- Looking for mach/mach.h -- Looking for mach/mach.h - not found -- Looking for histedit.h -- Looking for histedit.h - not found -- Looking for CrashReporterClient.h -- Looking for CrashReporterClient.h - not found -- Looking for linux/magic.h -- Looking for linux...

I had only a quick view on the blog-texts. It might be that a CLANG generated with LTO/PGO speeds up the build. Can you confirm this? Can you confirm binutils-gold speed up the build? Has LLVM an own linker? Can be used? Speedup the build? Yesterday night I loooked through available CMAKE/LLVM variables... ### GOLD # CMAKE_LINKER:FILEPATH=/usr/bin/ld #

Thanks, Andy. I'm not sure how to solve that or my case given the DAG's basic-block limit. Probably CodeGenPrepare or SelectionDAGBuilder...or we wait until after isel and try to split it up in a machine instruction pass. I filed my example here: https://bugs.llvm.org/show_bug.cgi?id=33013 Feel free to comment there and/or open a new bug for the FP_TO_UINT case. On Thu, May 11, 2017 at