similar to: [LLVMdev] compiler-rt's arm vfp o<= implementation

The implementation of an float ordered <= looks buggy, but maybe I'm not reading the assembly right. This is lesf2vfp.S in compiler-rt, and it has this code: // extern int __lesf2vfp(float a, float b); // // Returns one iff a <= b and neither is NaN. // Uses Darwin calling convention where single precision arguments are passsed // like 32-bit ints //

On Nov 11, 2009, at 3:27 AM, Rodolph Perfetta wrote: > > If you know about the alignment, maybe use structured load/store > (vst1.64/vld1.64 {dn-dm}). You may also want to work on whole cache > lines > (64 bytes on A8). You can find more in this discussion: > http://groups.google.com/group/beagleboard/browse_thread/thread/12c7bd415fbc >

Hello, on the problems cross-building compiler-rt: Tried to follow https://llvm.org/docs/HowToCrossCompileBuiltinsOnArm.html which lead to this cmake: cmake -G "Ninja" ../llvm/projects/compiler-rt/ -DCOMPILER_RT_BUILD_BUILTINS=ON -DCOMPILER_RT_BUILD_SANITIZERS=OFF -DCOMPILER_RT_BUILD_XRAY=OFF -DCOMPILER_RT_BUILD_LIBFUZZER=OFF -DCOMPILER_RT_BUILD_PROFILE=OFF

I have added new instructions to my target, unfortunately they are not being properly type legalized. The instructions I've added are a vector add, vector load and a vector store. Can anyone lend a hand on how to legalize them so that my target would be able to recognize them. Below is the output of llc with a -debug-only=isel. As you could see the output type for load, store, and add changes

Hello again! Tried out the small Hello World Setup, worked as intended: root at christian-forschung-virtual-machine:/home/progs# clang -v --target=arm-linux-gnueabihf hello.c -o hello -fuse-ld=lld clang version 8.0.0 (https://git.llvm.org/git/clang.git/ a152c7a4b7ba8f4cb9532ead9a38a7121db43d50) (https://git.llvm.org/git/llvm.git/ 1959ce6f3e01241919968ac1911fd45660239d23) Target:

Hello Peter and Lists, thanks a lot, that way it worked out! The final cmake was cmake -G "Ninja" ../llvm/projects/compiler-rt/ -DCOMPILER_RT_BUILD_BUILTINS=ON -DCOMPILER_RT_BUILD_SANITIZERS=OFF -DCOMPILER_RT_BUILD_XRAY=OFF -DCOMPILER_RT_BUILD_LIBFUZZER=OFF -DCOMPILER_RT_BUILD_PROFILE=OFF -DCMAKE_C_COMPILER=/usr/local/myclang/bin/clang -DCMAKE_AR=/usr/local/myclang/bin/llvm-ar

I tried to speed up Dhrystone on ARM Cortex-A8 by optimizing the memcpy intrinsic. I used the Neon load multiple instruction to move up to 48 bytes at a time . Over 15 scalar instructions collapsed down into these 2 Neon instructions. fldmiad r3, {d0, d1, d2, d3, d4, d5} @ SrcLine dhrystone.c 359 fstmiad r1, {d0, d1, d2, d3, d4, d5} It seems like this should be faster. But I did

Hi Siarhei, I've got the patch in my hands, sorry for the delay. It takes into account the MC emitting the .fpu when in ASM mode and the build attributes in both ASM and ELF mode. Jason, that's the patch I was talking about today. It's non-invasive and I'll send it no later than Monday, so should be in for the 2.9 release. cheers, --renato

On 27 May 2011 19:47, Jim Grosbach <grosbach at apple.com> wrote: > Not exactly. The distinction is clear, it's just not expressed as an > either/or question. Specifically, the code generator considers NEON to be a > proper superset of VFP3. So if it has only VFP3, that's all it will use. If > it has NEON, it assumes it also has VFP3 and can use either. Indeed. >

I'd greatly appreciate a pointer to where I could download this library. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111130/215348d5/attachment.html>

Hi... I'm trying to install over debian using wine a soft developed in VFP. The installer can be download from here: http://www.huskysoft.com/instalar%20husky%20pos.exe The problem is when I login correctly. It shows me a window with the message: "Se ha detectado un peque?o inconveniente en la configuracion de su pantalla. A continuacion salga del programa y reinicie su equipo."

On 27 May 2011 02:04, David Dunkle <ddunkle at arxan.com> wrote: > In all cases, I get code that looks pretty very the same; its like what > is below. However, I am expecting to see instruction level differences > between the vfp3 and neon versions. When I do the same with gcc 4.2 I do > see differences in the generated code. Hi David, You could see different instructions (as

On May 27, 2011, at 10:49 AM, David Dunkle wrote: > 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 >

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 locally, but as this is part of another set of patches we were waiting for it to stabilise. There are some

On Friday 25 February 2011 22:28:14 Jason Kim wrote: > 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

Hello again Christian, I've posted https://reviews.llvm.org/D55709 to see if we can get the documentation on how to cross-compile compiler-rt improved. I'll be out of office until next year so I may be a bit slow to respond to any follow ups. Peter On Thu, 13 Dec 2018 at 17:10, Peter Smith <peter.smith at linaro.org> wrote: > > Hello Christian, > > I've just

Hello Christian, I've put some comments inline, On Sun, 3 Feb 2019 at 13:11, Christian Richter <christian.richter at hsu-hh.de> wrote: > > Hello again, > > so after I successfully build the compiler-rt for armv6 I tried to > actually use it in compiling a small helloworld for a baremetal arm > (consisting of barehelloCLANG.c and a small io.h + io.c) , but the >

Hi, I have submitted a bug some time ago to LLVM bugtracker: http://llvm.org/bugs/show_bug.cgi?id=8931 The problem is that I'm trying to use clang in linux system, running on ARM hardware. And this bug, as trivial as it is, seems to be a major showstopper. I wonder if I'm the only one trying to use LLVM/clang in this configuration or doing something in an unusual way? Anyway, the LLVM

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

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