similar to: [LLVMdev] LLVM CodeGen Engineer job opening with Apple's compiler team

I have a code generation question for ARM with VFP and NEON. I am generating 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.

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

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

Hello, I'm trying to convince llc to compile into thumb2 ISA on ARMv7. I'm using: -march=thumb -mattr=v7,thumb2,vfp3 but llc complains about this with: llc: error: invalid target 'thumb -mattr=v7,thumb2,vfp3' I'm using LLVM from Aug 29 2011. To me the set of options looks sane so I'd like to ask what's wrong with this. Thanks! Karel

I am not using llvm tools, but sources and directly calling into relevant LLVM classes and methods. Thanks, Daman On 23/06/14 4:11 pm, "Amara Emerson" <amara.emerson at gmail.com> wrote: >Hi Damanjit, > >I assume you're trying to use the tools like llvm-mc, in which case >you can use the -mattr=+vfpv3 flag to enable it. This applies to other >subtarget

Hi Karel, It actually looks like the argument parser has parsed "thumb -mattr=v7,thumb2,vfp3" as the full argument to "-march=". Strange. The easiest way to get what you want is probably "-mtriple thumbv7--". v7 has Thumb2 enabled and VFPv3 (along with NEON) by default. Cheers, James ________________________________________ From: llvmdev-bounces at cs.uiuc.edu

How can I ensure use of VFP3 via LLVM target options? I am currently using thumbv7-windows-msvc as the target triple and default set of llvm::TargetOptions. Thanks, Daman -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140623/bdf36cce/attachment.html>

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:

Hi all, I'm hitting a segfault in llc when trying to build GHC: http://sprunge.us/ZVGB. What is the best way to debug this? I'm able to bump to 3.8.1 if needed, but GHC tends to break when updating major versions due to IR incompatibilities. Thanks, Shea -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size:

Hi Eli, Renato, Thanks for your feedback, there's a lot more to some of these things than I knew. I've addressed your points below. The overall summary is: - Start with converting the TargetParser to tableGen, with no user facing changes - Add warnings based on that, behind -Wall. Starting with command lines, since directives have larger implications that need investigation Thanks,

Hello, I've compiled today's LLVM on ARM/Linux machine and attempted to use our GHC/ARM port (which is using LLVM as a backend for generating machine code) with it but I've failed in compiling GHC alone as LLVM fails on me with following message: llc: /export/home/karel/vcs/llvm-ghc-arm/lib/CodeGen/MachineInstr.cpp:612: void llvm::MachineInstr::addOperand(const

Hi Karel, Mind trying again with current top of tree? Owen's fixed a few things today that were manifesting with that error. -Jim On Aug 29, 2011, at 2:33 PM, Karel Gardas wrote: > Hello, > > I've compiled today's LLVM on ARM/Linux machine and attempted to use our GHC/ARM port (which is using LLVM as a backend for generating machine code) with it but I've failed in

I found a fix! The first hunk of https://reviews.llvm.org/D17533 (lib/CodeGen/TargetFrameLoweringImpl.cpp) on top of 3.8.1 does the trick. Does llvm do patch releases of old versions? Davide Italiano <davide at freebsd.org> writes: > On Fri, Oct 21, 2016 at 6:19 AM, Shea Levy via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hi all, >> >> I'm hitting

Hello Team, Good Morning!! This is Vishnu Prasanth doing my master's thesis on improving llvm compiler optimization. Currently I am trying to build dragon egg and when I gave take, it is not getting recognized for ARM machine. Can you please help me with. Below are the errors when I gave the below command inside dragon egg directory GCC=GCC_DIR/gcc

Hi Jim and Eric! thanks a lot for your fantastically fast reply. I'm going to update and will report tomorrow when all the building is done. Thanks! Karel On 08/29/11 11:36 PM, Jim Grosbach wrote: > Hi Karel, > > Mind trying again with current top of tree? Owen's fixed a few things today that were manifesting with that error. > > -Jim > > On Aug 29, 2011, at 2:33

> ~/Desktop/Sanjeev/LLVM/llvm-2.7/Release/lib/libLLVMgold.so --eh-frame-hdr > -melf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o Ok, this way you're generating code for x86 > /usr/lib/crti.o > /usr/local/lib/gcc/i686-pc-linux-gnu/4.2.0/crtbegin.o > -L/usr/local/lib/gcc/i686-pc-linux-gnu/4.2.0  -L/usr/local/lib -lgcc > --as-needed -lgcc_s --no-as-needed -lc -lgcc

On 15 September 2015 at 21:58, Jim Grosbach <grosbach at apple.com> wrote: > That’s not quite accurate. It’s not A9+HDIV+VFP. It uses the A9 scheduling model, yes, but has its own completely distinct list of sub target features and such: Well, this is the target description in the TableGen files, and not exactly what I was talking about. when available, A9 has VFP3, while Krait has VFP4.

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