similar to: [LLVMdev] VFP3

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

On Wed, Jun 18, 2014 at 10:25 AM, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > On Wed, Jun 18, 2014 at 9:09 AM, Damanjit Singh <dsingh at adobe.com> wrote: > >> Hi Saleem, >> >> Though a simple app works great I am facing few issues trying to link a >> slightly complex object file, generated via LLVM, with some libs generated >> via

Thanks Saleem, Nick. I will try with the latest code and share the results. Though, just curious if I need to really use clang to generate the object file and the current steps won't work? I ask because using .c file was only an illustration. For my project the IR is not generated from .c files or clang. Thanks, Daman Sent from my phone On 08-Jun-2014, at 11:00 am, "Saleem

Thanks a lot Saleem, The issue is fixed and a simple app works fine now. -Daman On 08/06/14 12:57 pm, "Nick Lewycky" <nicholas at mxc.ca> wrote: >Damanjit Singh wrote: >> Thanks Saleem, Nick. >> >> I will try with the latest code and share the results. >> >> Though, just curious if I need to really use clang to generate the >> object file

Hi Saleem, Though a simple app works great I am facing few issues trying to link a slightly complex object file, generated via LLVM, with some libs generated via Visual Studio - 1. Seems IMAGE_SCN_MEM_16BIT is only written for the the first header in the COFF file, thus functions in other headers (if you are using function sections) don’t work. I was able to workaround this by forcing this entry

Damanjit Singh wrote: > Hi guys, > > Would really appreciate any help here. > > Thanks, > Daman > > From: Damanjit Singh <dsingh at adobe.com <mailto:dsingh at adobe.com>> > Date: Friday, 6 June 2014 12:57 pm > To: "llvmdev at cs.uiuc.edu <mailto:llvmdev at cs.uiuc.edu>" > <llvmdev at cs.uiuc.edu <mailto:llvmdev at

Hi LLVMdev, Does the latest trunk code support Windows Phone 8.1 target ? I was trying out a simple program, but Visual Studio 2013's linker failed for me with this error - app.obj : error LNK2008: Fixup target is not aligned 'add3' This is what I tried - * Download latest LLVM sources (as on 4th June) and build them on my MAC 10.9 machine. * Wrote a simple a.c, with add3

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

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:

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

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

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>

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,

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

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.

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 >

Hi all, LLVM CodeGen and Tools team at Apple is looking for exceptional compiler engineers. This is a great opportunity to work with many of the leaders in the LLVM community. If you are interested in this position, please send your resume / CV and relevant information to evan.cheng at apple.com Thanks, Evan Job description The Apple compiler team is seeking an engineer who is strongly

On 3 July 2011 21:32, Karel Gardas <karel.gardas at centrum.cz> wrote: > please see http://ghcarm.wordpress.com/2011/07/03/llvm-on-arm-testing/ > > Is there anything other I might do for you to get those regressions fixed? Hi Karel, This is great! I can see there's only a handful of errors. All JIT errors seem to be the same (MC). All O2 errors, too (MIPS). The select.ll