search for: neonfp

...-math enables far too many different things for it to be "the canonical switch" for just about any transformation. Rather, it should be what I think it is in gcc which is an effectively a short-cut for invoking of several individual math-option flags. [snip] |I just looked again at the +neonfp flag. Compiling with and without |+neonfp flag seems to only affect scalar types in the attached test |case. If e.g. the LLVM vectorizer introduces vector instructions on |LLVM-IR level floating point vectors still yield NEON assembly even if |compiled with "-mattr=+neon,-neonfp". Is...

> |I just looked again at the +neonfp flag. Compiling with and without > |+neonfp flag seems to only affect scalar types in the attached test > |case. If e.g. the LLVM vectorizer introduces vector instructions on > |LLVM-IR level floating point vectors still yield NEON assembly even if > |compiled with "-mattr=+neon,-n...

...n't have any opinion on for clang. The best is probably to mirror the gcc behavior on linux targets. My current goal is to understand the implications of certain features and to make sure a tool using the LLVM back-ends can actually implement any policy it likes. I just looked again at the +neonfp flag. Compiling with and without +neonfp flag seems to only affect scalar types in the attached test case. If e.g. the LLVM vectorizer introduces vector instructions on LLVM-IR level floating point vectors still yield NEON assembly even if compiled with "-mattr=+neon,-neonfp". Is this...

...'s possible that some passes are not consulting that flag when generating NEON SP-FP. If that's true, this is definitely a bug. When I changed that, for VMUL.f32, it worked (ie. generated VFP instruction), but it might not be taking the same path your code is. I just looked again at the +neonfp flag. Compiling with and without +neonfp > flag seems to only affect scalar types in the attached test case. If e.g. > the LLVM vectorizer introduces vector instructions on LLVM-IR level > floating point vectors still yield NEON assembly even if compiled with > "-mattr=+neon,-neonf...

On 7 June 2013 07:05, Owen Anderson <resistor at mac.com> wrote: > Darwin uses NEON for floating point, but does *not* (and should not). > globally enable fast math flags. Use of NEON for FP needs to remain > achievable without globally setting the fast math flags. Fast math may > imply reasonably imply NEON, but the opposite direction is not accurate. > > That said, I

...passes are not consulting that flag when generating NEON SP-FP. If that's true, this is definitely a bug. > > When I changed that, for VMUL.f32, it worked (ie. generated VFP instruction), but it might not be taking the same path your code is. > > > I just looked again at the +neonfp flag. Compiling with and without +neonfp flag seems to only affect scalar types in the attached test case. If e.g. the LLVM vectorizer introduces vector instructions on LLVM-IR level floating point vectors still yield NEON assembly even if compiled with "-mattr=+neon,-neonfp". Is this exp...

...onsulting that flag when generating NEON SP-FP. If that's true, this is definitely a bug. >> >> When I changed that, for VMUL.f32, it worked (ie. generated VFP instruction), but it might not be taking the same path your code is. >> >> >> I just looked again at the +neonfp flag. Compiling with and without +neonfp flag seems to only affect scalar types in the attached test case. If e.g. the LLVM vectorizer introduces vector instructions on LLVM-IR level floating point vectors still yield NEON assembly even if compiled with "-mattr=+neon,-neonfp". Is this exp...

Thanks andrew for the answer. I would like to generate code for Cortex-A9 that don't use neon for fp computation but vfpv3 -d16. I've tried some combination of -mattr=+neon,-neonfp,+vfp3,+d16 but couldn't get ".fpu vfpv3-d16" directive generated in assembly file. Do you know how to make it happen ? Best Regards Seb From: Andrew Trick [mailto:atrick at apple.com] Sent: Saturday, July 28, 2012 2:46 AM To: Sebastien DELDON-GNB Cc: llvmdev at cs.uiuc.edu Subject:...

Hi all, More on this topic, if I use llc 3.1 with -promote-elements=0 as follows: llc convect.llvm -march=arm -mcpu=cortex-a9 -promote-elements=0 -mattr=+neon,+neonfp -relocation-model=pic -o convect.s then it fails, whereas it compiles with promote elements set to 1, trace looks like: # In Register Scavenger # Machine code for function test_kernel: Post SSA Frame Objects: fi#-18: size=4, align=8, fixed, at location [SP+264] ... Function Live Ins: %R2 in %...

Hi Anton, You're right it fails with a different message with llc 3.0. Anyway thanks for your help. Best Regards Seb > -----Original Message----- > From: Anton Korobeynikov [mailto:anton at korobeynikov.info] > Sent: Monday, June 25, 2012 3:39 PM > To: Sebastien DELDON-GNB > Cc: LLVMdev at cs.uiuc.edu; Rotem, Nadav > Subject: Re: RE : [LLVMdev] Is llc broken for Cortex-A9

On Jul 27, 2012, at 9:04 AM, Sebastien DELDON-GNB <sebastien.deldon at st.com> wrote: > Hi all, > > Does llc –march=thumb –mcpu=cortex-a9 enable generation of thumb2 code for armv7 ? That's how I usually do it. Somewhere in the target description we associate a9 with -mattr=+thumb2. There are plenty of other ways to get the same result, and it's all very confusing and

Hi all, Does llc -march=thumb -mcpu=cortex-a9 enable generation of thumb2 code for armv7 ? Best Regards Seb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120727/da758ea0/attachment.html>

...i8> tail call arm_aapcscc void @zzz(<2 x i8> %1, <2 x i8> %4) ret void } declare arm_aapcscc void @zzz(<2 x i8>, <2 x i8>) using llc as follows: llc bugparam.ll -march=arm -mcpu=cortex-a9 -mattr=+neon,+neonfp -relocation-model=pic -o bugparam.s with LLVM 3.0, it works, with LLVM 3.1 generated code contains a misaligned load: bar: @ @bar @ BB#0: @ %L.entry push {r11, lr} add r0, r1, #2 vldr s0, [r1]...

...tcast i16 %3 to <2 x i8> > tail call arm_aapcscc void @zzz(<2 x i8> %1, <2 x i8> %4) > ret void > } > > declare arm_aapcscc void @zzz(<2 x i8>, <2 x i8>) > > using llc as follows: > llc bugparam.ll -march=arm -mcpu=cortex-a9 -mattr=+neon,+neonfp -relocation-model=pic -o bugparam.s > > with LLVM 3.0, it works, with LLVM 3.1 generated code contains a misaligned load: > > bar: @ @bar > @ BB#0: @ %L.entry > push {r11, lr} > add r0, r1, #2 >...

Hi Sebastien, > Thanks for the quick answer, how do I know which type is legal/illegal with respect to calling convention ? the code generators are supposed to produce working code no matter what the parameter type is. The fact that the ARM ABI doesn't specify how <2 x i8> is passed just means that the code generators can pass it using whatever technique it feels like (since it

Hi Rotem, Thanks for the quick answer, how do I know which type is legal/illegal with respect to calling convention ? Best Regards Seb > -----Original Message----- > From: Rotem, Nadav [mailto:nadav.rotem at intel.com] > Sent: Thursday, July 05, 2012 11:21 AM > To: Sebastien DELDON-GNB; llvmdev at cs.uiuc.edu > Subject: RE: Vector argument passing abi for ARM ? > > The