similar to: [LLVMdev] NEON lowering errors in Clang/LLVM

Dear all. I built the LLVM 3.0 rc4 with Clang front-end in windows os env. (also with -DLLVM_TARGETS_TO_BUILD=all option) For arm neon intrinsics testing, I tried to compile some codes, which are included a few neon intrinsics. Although I got a well done bitcode on ubuntu build pc, it shows some errors when compile the codes on windows. Could you let me know why occurred errors? is this just a

I'm trying to do a standalone build of Opus and I get the following messages when compiling for android arm64 using clang:   CC       silk/fixed/arm/warped_autocorrelation_FIX_neon_intr.lo silk/fixed/arm/warped_autocorrelation_FIX_neon_intr.c:43:37: warning: incompatible pointer types assigning to 'const long *' from 'long long *' [-Wincompatible-pointer-types]    

On Tue, Sep 21, 2010 at 11:07 PM, Alasdair Grant <Alasdair.Grant at arm.com> wrote: > Bob Wilson writes: >> On Sep 21, 2010, at 9:33 AM, Renato Golin wrote: >> > I was checking NEON instructions this week and the vector types seem >> > to be inside structures. If vector types are considered proper types >> > in LLVM, why pack them inside structures?

Bob Wilson writes: > On Sep 21, 2010, at 9:33 AM, Renato Golin wrote: > > I was checking NEON instructions this week and the vector types seem > > to be inside structures. If vector types are considered proper types > > in LLVM, why pack them inside structures? > > Because that is what ARM has specified? They define the vector types > that are used with their NEON

Hello Renato, It turned out I just didn't do the cross-compilation correctly, and Tim Northover already pointed me to a guide you have written on it ( http://clang.llvm.org/docs/CrossCompilation.html), so I will read that before continuing with my efforts. To answer your question I am testing on a pandaboard currently, which has an arm cortex-a9 processor, which I think is 64-bit. I am much

Hi, I'm trying to compile half precision program for ARM, while it seems LLVM fails to automatically generate fused-multiply-add instructions for c += a * b. I'm wondering whether I did something wrong, if not, is it a missing feature that will be supported later? (I know there're fp16 FMLA intrinsics though) Test programs and outputs, $ clang -O3 -march=armv8.2-a+fp16fml

Hi, Compiling on PP64/FreeBSd, I get several of these: /usr/home/kparzysz/bld.lv/tools/llvm-mc/Release+Asserts/llvm-mc.o: In function `llvm::formatted_raw_ostream::~formatted_raw_ostream()': llvm-mc.cpp:(.text.startup.main+0xe4): undefined reference to `LLVMInitializeARM64TargetInfo' llvm-mc.cpp:(.text.startup.main+0x154): undefined reference to `LLVMInitializeARM64TargetMC'

On Sep 21, 2010, at 12:28 PM, Renato Golin wrote: > On 21 September 2010 20:02, Bob Wilson <bob.wilson at apple.com> wrote: >> That code is to support reading old bitcode files containing intrinsics that no longer exist or that have different arguments/usage than in previous versions of llvm. It's not a validation pass, and it's not relevant to any new IR. It's only

On 21 September 2010 20:30, Bob Wilson <bob.wilson at apple.com> wrote: > The intrinsics that have been removed are no longer defined, so I don't see how ARMInstrNEON.td could be using them.  I really don't know what you're referring to, though. Hi Bob, Example: lib/VMCore/AutoUpgrade.cpp:91: Name.compare(14, 5, "vabal", 5) == 0) &&

On Sep 28, 2010, at 2:07 AM, Renato Golin wrote: > On 27 September 2010 23:45, Bob Wilson <bob.wilson at apple.com> wrote: >> An implementation, such as in GCC, that does not use structures is compatible with ARM's specification in only one direction. GCC will accept any code written for RVCT, but not the other way around. And, as Al pointed out, there are also compatibility

On Sep 21, 2010, at 1:03 PM, Renato Golin wrote: > On 21 September 2010 20:30, Bob Wilson <bob.wilson at apple.com> wrote: >> The intrinsics that have been removed are no longer defined, so I don't see how ARMInstrNEON.td could be using them. I really don't know what you're referring to, though. > > Hi Bob, > > Example: > >

On Sep 21, 2010, at 4:33 PM, Sandeep Patel wrote: > On Tue, Sep 21, 2010 at 11:07 PM, Alasdair Grant <Alasdair.Grant at arm.com> wrote: >> Bob Wilson writes: >>> On Sep 21, 2010, at 9:33 AM, Renato Golin wrote: >>>> I was checking NEON instructions this week and the vector types seem >>>> to be inside structures. If vector types are considered

Thanks for reply. I was using LLVM 8.0. Let me try trunk and will let you know if it works. On Wed, Sep 4, 2019 at 11:19 PM Sjoerd Meijer <Sjoerd.Meijer at arm.com> wrote: > > Hi, > Which version of Clang are you using? I do get a "vfma.f16" with a recent trunk build. I haven't looked at older versions and when this landed, but we had an effort to plug the remaining

Hello, I totally understood about this problem. codesourcery codebench arm eabi version uses newlibc. but, arm gnu/linux version uses glibc. hm.. actually there is no problem. it was my mistake as james told me. Thanks. 2011/11/24 Seung-yeon Choe <sychoe at gmail.com> > Hello, James Molly. > > Thank you for your advices. > > Now I aware that this is the problem of

Hello, James Molly. Thank you for your advices. Now I aware that this is the problem of stdint.h. And, codesourcery toolchain also has stdint.h header file at same place of stdio.h Generally, Clang has "lib/clang/3.0/include" default search path. If I added codesourcery toolchain path for stdio.h with -I option, stdint.h has been loaded at the specified toolchain path first cuz

On Sep 27, 2010, at 3:23 PM, Renato Golin wrote: > On 27 September 2010 23:03, Bob Wilson <bob.wilson at apple.com> wrote: >> Can you clarify ARM's position on those structure types? It sounds like you are advocating that we get rid of them. The only reason we've been using them in llvm-gcc and clang is for compatibility for ARM's specifications and with ARM's

On Sep 21, 2010, at 10:14 AM, Renato Golin wrote: > On 21 September 2010 18:03, Bob Wilson <bob.wilson at apple.com> wrote: >> Because that is what ARM has specified? They define the vector types that are used with their NEON intrinsics as "containerized vectors". Perhaps someone on the list from ARM can explain why they did it that way. > > That's ok, but

On 21 September 2010 20:02, Bob Wilson <bob.wilson at apple.com> wrote: > That code is to support reading old bitcode files containing intrinsics that no longer exist or that have different arguments/usage than in previous versions of llvm.  It's not a validation pass, and it's not relevant to any new IR.  It's only for backward compatibility. Oh, I see. So we should also

Hi, There is a little bit awkward thing. If I need to use the newlibc printf function regardless stdint.h is compiler specific implementation, I should remove or block newlibc's stdint.h and the others because as you know clang already stdint.h (glibc compatible??) header but it is not standard library full set, right? On the other hand, even if I want to use other toolchain's glibc

Viswanath Puttagunta wrote: > + SUMM = vdupq_n_f32(0); It kills me that there's no intrinsic for VMOV.F32 d0, #0 (or at least I couldn't find one), so this takes two instructions instead of one. > + /* Consume 4 elements in x vector and 8 elements in y > + * vector. However, the 8'th element in y never really gets > + * touched in this loop. So, if len == 4,