search for: mfpu

...vector FP math? TTI seems like a good place to expose that information. If the semantics are indeed different, then the vectorizer would require fast-math flags in order to vectorize FP operations (similarly, gcc's man page says it requires -funsafe-math-optimizations for vectorization unless -mfpu=neon or similar is specified). In this context, this different-semantics query would return true if: The semantics is indeed different, VFP is IEEE-754 compliant while NEON is not. We don't want to stop the compiler from using VFP for FP math, but we want to be cautious when using NEON in the...

...; a good place to expose that information. If the semantics are indeed > > different, then the vectorizer would require fast-math flags in order to > > vectorize FP operations (similarly, gcc's man page says it requires > > -funsafe-math-optimizations for vectorization unless -mfpu=neon or similar > > is specified). In this context, this different-semantics query would return > > true if: > > The semantics is indeed different, VFP is IEEE-754 compliant while > NEON is not. We don't want to stop the compiler from using VFP for FP > math, but we wan...

...s and see how it goes. >> they're the only negative features that are relevant for TargetParser? Yes, the rest are for internal use aka not enabled by a specific option. For a particular CPU for example. 'auto' FPU value (Renato) ================ >> I'd have assumed -mfpu is already "auto" by default. Or is this to >> just override a previous option? >> >> ex: clang -mcpu cortex-a8 -mfpu vfp4 -mfpu auto -> defaults back to VFP3. I don't see any reference to this in the code or the docs, and clang something similair: ./clang --targ...

...vector FP math? TTI seems like a good place to expose that information. If the semantics are indeed different, then the vectorizer would require fast-math flags in order to vectorize FP operations (similarly, gcc's man page says it requires -funsafe-math-optimizations for vectorization unless -mfpu=neon or similar is specified). In this context, this different-semantics query would return true if: !(isDarwin OR ARMISA >= v8 OR fpMath == NEON) and then we need to teach people to use -mfpu=neon ;) I think this more-or-less matches what you've proposed. Is that right? -Hal P.S. Lo...

On 22 March 2016 at 11:34, James Molloy <James.Molloy at arm.com> wrote: > I don’t think this part is right. The denormal flag would have to be set by > whatever code generates the FP instruction, which would be Clang’s codegen > layer. So the if (Darwin) would be there, not in TTI. Right, I meant the information to set/not set would be in TTI, not the actual setting. I don't

...39;+<ext>' | Y | Y | Y | Y | | checks extensions | Y | N | N | N | | .arch with '+<ext>' | N | N | N | Y | | .arch_extension | Y | Y | Y | N | | .fpu | Y | N | Y | N | | -mfpu | Y | N | Y | N | | checks FPUs | N | n/a | N | n/a | |----------------------|-----|---------|-----|---------| Examples of each of these can be found at the end of this document. Problems With the Current Options --------------------------------...

...39;+<ext>' | Y | Y | Y | Y | | checks extensions | Y | N | N | N | | .arch with '+<ext>' | N | N | N | Y | | .arch_extension | Y | Y | Y | N | | .fpu | Y | N | Y | N | | -mfpu | Y | N | Y | N | | checks FPUs | N | n/a | N | n/a | |----------------------|-----|---------|-----|---------| Examples of each of these can be found at the end of this document. Problems With the Current Options --------------------------------...

...39;+<ext>' | Y | Y | Y | Y | | checks extensions | Y | N | N | N | | .arch with '+<ext>' | N | N | N | Y | | .arch_extension | Y | Y | Y | N | | .fpu | Y | N | Y | N | | -mfpu | Y | N | Y | N | | checks FPUs | N | n/a | N | n/a | |----------------------|-----|---------|-----|---------| Examples of each of these can be found at the end of this document. Problems With the Current Options --------------------------------...

...the cross-compilation LLVM documentation [1], I am trying to target the ARM on the Zedboard [2]. It is an ARM Cortex-A9. The machine I am compiling on is an x86_64 Fedora Linux machine, using clang 3.3. I am failing to generate an executable, instead seeing an error "unrecognized option '-mfpu=neon'". $ clang -v -target armv7a-linux-eabi -mcpu=cortex-a9 -mfloat-abi=soft -mfpu=neon helloworld.c clang version 3.3 (tags/RELEASE_33/rc3) Target: armv7a--linux-eabi Thread model: posix "/usr/bin/clang" -cc1 -triple armv7--linux-eabi -S -disable-free -disable-llvm-verifier -...

...Bosch, Germany. We are using armv8 64bit targets for our development. We have the need to do the cross compiling for our target on windows. I have compiled clang 5.0 from the vcs git. I have tried compiling the code with following options set: clang.exe -target armv8 -fslp-vectorize-aggressive -mfpu=neon -mfloat-abi=hard -c test.cpp As you can see in the options, we require neon feature as well as auto vectorizations on armv8 (64 bit). Can you tell me that is it true that clang supports neon and auto vectorizations with 64bit arm v8 architecture? This setting says that neon is not in support...

...ing code for the following function as a test: void FloatingPointTest(float f1, float f2, float f3) { float f4 = f1 * f2; if (f4 > f3) printf("%f\n",f2); else printf("%f\n",f3); } I have tried compiling with: 1. -mfloat-abi=softfp and -mfpu=neon 2. -mfloat-abi=hard and -mfpu=neon 3. -mfloat-abi=softfp and -mfpu=vfp3 4. -mfloat-abi=hard and -mfpu=vfp3 When I use --emit-llvm -c flags to generate bitcode, and then use llc to generate ARM assembler, I have tried supplying these flag variations to llc: 5. llc -mattr=+neon...

On 26 November 2013 15:36, Rob Stewart <robstewart57 at gmail.com> wrote: > $ clang -v -target armv7a-linux-eabi -mcpu=cortex-a9 -mfloat-abi=soft > -mfpu=neon helloworld.c > Hi Rod, You need cross-binutils installed on your box. If you use Debian, there are packages (gcc-4.7-arm-linux-gnueabi and friends). Other distros may have similar packages, but you can always download the Linaro toolchain ( http://releases.linaro.org/latest/components/too...

Hi, Clang for AArch64 currently accepts an -mfpu option to specify the FPU/NEON unit. This behaviour, while consistent with the ARM target and ARM gcc, will no longer be supported in AArch64 gcc. The preferred CLI for specifying FPU/NEON units will be the use of the -march option with feature modifiers (+[no]feature). The feature modifiers accord...

...ecution time due to floating point operations, it was clearly observed that gcc used floating point instruction FSQRT, where as clang seemed to use emulated function (?) BL SQRT. Note that we used the following flags for both clang as well as gcc compilation. -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -mtune=cortex-a8 Infact, i was surprised to see that even when " -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mtune=cortex-a8" was used, the code generated did not use hardware vsqrt instruction, instead there was a bl sqrt instruction. Could someone point out why vsqrt...

...or >> >> and dmesg agrees: >> >> [ 96.272849] Alignment trap: not handling instruction f4400add at [<b4072ffc>] >> [ 96.280467] Unhandled fault: alignment exception (0x801) at 0x01d7a8cc >> >> Might this be due to the fact that I now compile with -mfpu=neon ? > > Ismail, > > I'm really sorry for not looking into this when I should, you're > absolutely correct. Here's the bug: > > http://llvm.org/bugs/show_bug.cgi?id=22375 > > I'm self-hosting the release r223766 and found many Clang segfaults, > thoug...

Hi all, LLVM CodeGen and Tools team at Apple is looking for exceptional compiler engineers. This is a great opportunity to work with many of the leaders in the LLVM community. If you are interested in this position, please send your resume / CV and relevant information to evan.cheng at apple.com Thanks, Evan Job description The Apple compiler team is seeking an engineer who is strongly

...ied the x86 suggestion but it didn't work. Clearly I'm doing something wrong, but I don't know what exactly. I would really appreciate your help in this. Here is the command line I'm using clang -S test.c -o test.sse2.x86_64.s --target=x86_64-pc-linux-gnu -mfloat-abi=hard -mcpu=k8 -mfpu=SSE2 -fslp-vectorize-aggressive -fslp-vectorize-aggressive -fslp-vectorize -fvectorize -fno-lax-vector-conversions -O3 Here is the response that I get: clang-3.5: warning: argument unused during compilation: '-mfloat-abi=hard' clang-3.5: warning: argument unused during compilation: '-...

...tions. I need to see how they look, whether it is ARM, Mips or X86. However for some reason clang would generate an error saying that a given target does not exist. Here is the command line I used: clang -S test.c -o test.sse2.x86-64.s --target=x86-unknown-linux-eabi -mfloat-abi=hard -mcpu=x86-64 -mfpu=SSE2 -fslp-vectorize-aggressive -fslp-vectorize-aggressive -fslp-vectorize -fvectorize -fno-lax-vector-conversions Here is the response I got: clang: warning: argument unused during compilation: '-mfloat-abi=hard' clang: warning: argument unused during compilation: '-mcpu=x86-64' c...

Thanks, that helps a lot. > All chips (to date) with NEON have VFP3, so it's safe to assume that a -mfpu=neon will have VFP3, so all the decisions > about code generated for VFP3 can safely be assumed by targets with NEON. Just to confirm my understanding, can I correctly say in general that the llc code generator might blur distinctions between NEON and VFP3 when it can do so safely? -David -...

...n execution time due to floating point operations, it was clearly observed that gcc used floating point instruction FSQRT, where as clang seemed to use emulated function (?) BL SQRT. Note that we used the following flags for both clang as well as gcc compilation. -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -mtune=cortex-a8 Infact, i was surprised to see that even when " -march=armv7-a -mfloat-abi= *hard* -mfpu=vfpv3-d16 -mtune=cortex-a8" was used, the code generated did not use hardware *vsqrt* instruction, instead there was a *bl sqrt* instruction. Could someone point out why *vs...