search for: vfpv2

...of how yours would look like in a sample Module? Something similar to yours: !llvm.module.flags.lto = !{ !0, !1 } !llvm.module.flags.cg = !{ !0 } !0 = metadata !{ i32 1, metadata !"soft-float", i1 true } // forcing soft float all the way through !1 = metadata !{ i32 1, metadata !"VFPv2", i1 false } // The user do not want VFPv2 at all costs My proposal is more than just what it looks like in the IR, I don't really care that much about that. My points: 1. Dropping general info into metadata is not enough. You need to make sure it'll be semantically correct for the...

On Apr 30, 2012, at 1:03 AM, Renato Golin wrote: > On 29 April 2012 23:44, Bill Wendling <wendling at apple.com> wrote: >> Hi, >> >> Link-Time Optimization has a problem. We need to preserve some of the flags with which the modules were compiled so that the semantics of the resulting program are correct. For example, a module compiled with `-msoft-float' should use

...ule? > > Something similar to yours: > > !llvm.module.flags.lto = !{ !0, !1 } > !llvm.module.flags.cg = !{ !0 } > > !0 = metadata !{ i32 1, metadata !"soft-float", i1 true } // forcing > soft float all the way through > !1 = metadata !{ i32 1, metadata !"VFPv2", i1 false } // The user do > not want VFPv2 at all costs > > > My proposal is more than just what it looks like in the IR, I don't > really care that much about that. > > My points: > 1. Dropping general info into metadata is not enough. You need to > make su...

...FPU type + if (Subtarget->hasNEON()) + OutStreamer.EmitRawText(StringRef("\t.fpu neon")); + else if (Subtarget->hasVFP3()) + OutStreamer.EmitRawText(StringRef("\t.fpu vfpv3")); + else if (Subtarget->hasVFP2()) + OutStreamer.EmitRawText(StringRef("\t.fpu vfpv2")); + if (Subtarget->hasVFP2()) AttrEmitter->EmitAttribute(ARMBuildAttrs::VFP_arch, 2); It does not matter if you use this particular code or some other variant, but please just fix it somehow :) -- Best regards, Siarhei Siamashka

On Fri, Feb 25, 2011 at 12:16 PM, Siarhei Siamashka <siarhei.siamashka at gmail.com> wrote: > On Thursday 03 February 2011 14:14:28 Renato Golin wrote: >> On 3 February 2011 10:25, Siarhei Siamashka <siarhei.siamashka at gmail.com> > wrote: >> > I have submitted a bug some time ago to LLVM bugtracker: >> > http://llvm.org/bugs/show_bug.cgi?id=8931 >>

On Thursday 03 February 2011 14:14:28 Renato Golin wrote: > On 3 February 2011 10:25, Siarhei Siamashka <siarhei.siamashka at gmail.com> wrote: > > I have submitted a bug some time ago to LLVM bugtracker: > > http://llvm.org/bugs/show_bug.cgi?id=8931 > > Hi Siarhei, > > This is a really silly bug with a simple fix. > > We have a similar patch here

As reported in an earlier thread (http://clang-developers.42468.n3.nabble.com/Disable-memset-synthesis-tp4057810.html), we noticed in some cases that the llvm.memset intrinsic, if lowered to stores, could help with performance. Here's a test case: If LIMIT is > 8, I see that a call to memset is emitted for arm & aarch64, but not for x86 target. typedef struct { int v0[100]; }

...names are not checked against the base arch or CPU. This is correctly rejected from a command line: $ ./arm-eabi-gcc -march=armv6zk+neon -c /tmp/test.s -o /tmp/test.o arm-eabi-gcc: error: 'armv6zk' does not support feature 'neon' arm-eabi-gcc: note: valid feature names are: fp nofp vfpv2 Whereas the directive is accepted: $ cat /tmp/test.s .fpu neon nop $ ./arm-eabi-gcc -march=armv6zk -c /tmp/test.s -o /tmp/test.o For AArch64 .fpu is removed in favour of .arch_extension. Instead of directly selecting an FPU it is implied by the extensions used. $ cat /tmp/test.s .fpu neon $ ./aa...

...names are not checked against the base arch or CPU. This is correctly rejected from a command line: $ ./arm-eabi-gcc -march=armv6zk+neon -c /tmp/test.s -o /tmp/test.o arm-eabi-gcc: error: 'armv6zk' does not support feature 'neon' arm-eabi-gcc: note: valid feature names are: fp nofp vfpv2 Whereas the directive is accepted: $ cat /tmp/test.s .fpu neon nop $ ./arm-eabi-gcc -march=armv6zk -c /tmp/test.s -o /tmp/test.o For AArch64 .fpu is removed in favour of .arch_extension. Instead of directly selecting an FPU it is implied by the extensions used. $ cat /tmp/test.s .fpu neon $ ./aa...

...names are not checked against the base arch or CPU. This is correctly rejected from a command line: $ ./arm-eabi-gcc -march=armv6zk+neon -c /tmp/test.s -o /tmp/test.o arm-eabi-gcc: error: 'armv6zk' does not support feature 'neon' arm-eabi-gcc: note: valid feature names are: fp nofp vfpv2 Whereas the directive is accepted: $ cat /tmp/test.s .fpu neon nop $ ./arm-eabi-gcc -march=armv6zk -c /tmp/test.s -o /tmp/test.o For AArch64 .fpu is removed in favour of .arch_extension. Instead of directly selecting an FPU it is implied by the extensions used. $ cat /tmp/test.s .fpu neon $ ./aa...