similar to: [LLVMdev] LLC ARM Backend maintainer

Hi, Anton Korobenikov is the designated "maintainer", but ARM is one of the most active targets so plenty of people commit to it. We at ARM also commit to the back end. In general any questions you would ask a maintainer you should just post to the list and people will reply. Cheers, James ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces

Hi James, > Anton Korobenikov is the designated "maintainer", I really-really don't know who said this at first. I'm definitely *not* a maintainer. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hi Anton, I do apologise - I was under the impression that you were. Re-reading http://llvm.org/docs/DeveloperPolicy.html#owners, I see you're actually down for EH, debug info and Windows. Sorry about that! J ________________________________________ From: Anton Korobeynikov [anton at korobeynikov.info] Sent: 05 October 2011 20:46 To: James Molloy Cc: Seb; llvmdev at cs.uiuc.edu Subject: Re:

On Oct 7, 2011, at 1:07 AM, Seb wrote: > Hi all, > > To answer Eli question, I wanted to know who is actively working on ARM because I submitted some bug report (#11029, #9905) and don't know if someone is working on them, if/when the will be fixed. Maybe I just need to better understand LLVM release process, I've seen a mail in this list about it. Bugs get fixed if there are

Hi all, To answer Eli question, I wanted to know who is actively working on ARM because I submitted some bug report (#11029, #9905) and don't know if someone is working on them, if/when the will be fixed. Maybe I just need to better understand LLVM release process, I've seen a mail in this list about it. -- Seb -------------- next part -------------- An HTML attachment was scrubbed...

No. Note the qualifying phrase "for releases" on Tanya's statement. If, during release testing, a regression is found on ARM compared to 2.9 results, it is not required by process to be considered a release blocker. That does not mean features can or should be enabled which knowingly break ARM. That's an entirely different situation. -Jim On Oct 8, 2011, at 9:59 AM, Rotem,

Hi Tanya, The new type-legalization mode (-promote-elements) which enables vector-select in LLVM (and a nice perf boost for several workloads), is currently disabled because of a _single_ bug in the ARM codegen which makes a few tests fail. If ARM is not a supported target, can I mark these tests as 'XFAIL' and enable vector-select support in LLVM ? Thanks, Nadav -----Original

I am very interested in seeing a qualification plan for ARM given that it is a widely used target with several combinations of options/modes to be tested. I & my team use ARM hardware for running tests and we run all LLVM test suite tests as part of qualification process. I had started a similar conversation in llvm-commits, but this is probably the right forum. It will save everyone a lot of

Hi James, Thanks for the answer, can you elaborate on difference between thumb, thumb2, ARM, thumbv7. I'm a bit lost right now. When specifying thumbv7 llc will generate thumb only code, not thumb2 ? Best Regards Seb > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of James Molloy > Sent: Tuesday, May 29,

Hi Seb, The ARM instruction set is a fixed-width 32-bit instruction set that has been around since the early days of ARM. Modern (armv4t onwards) cores mostly have another instruction set that can be used in tandem, the "thumb" instruction set. This is a variable width (16 or 32 bit) instruction set that provides a subset of the ARM instruction set and was intended to provide the

Hi James, Thanks for the answer, for Cortex-A9 would you recommend to generate thumb2 code or ARM code ? What would be the best performance wise ? Best Regards Seb > -----Original Message----- > From: James Molloy [mailto:james.molloy at arm.com] > Sent: Thursday, May 31, 2012 9:57 AM > To: Sebastien DELDON-GNB > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] llc support

Hi James, I fully agree with you and understand your statement about -O2. Now some questions for you: Did you try to reproduce experiments described in my previous e-mail ? Did you look at debug informations generated for 'n' parameter on x86 32-bit & x86 64-bit ? I'm working on my own front-end for LLVM and I had difficulties with debug information when they are related to x86

Hi, It goes without saying that I +1 this. Cheers, James -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Raja Venkateswaran Sent: 11 October 2011 17:46 To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] LLC ARM Backend maintainer I am very interested in seeing a qualification plan for ARM given that it is a widely used

Hi all, Can someone give me advice on what should be a good definition of target datalayout for an ARM cortex-A9 + neon target and x86 32-bit ? Shall I use a different definition for a cortex-A9 without neon ? Thanks for your advices Best Regards Seb -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Wed, Mar 7, 2012 at 6:50 AM, Seb <babslachem at gmail.com> wrote: > Hi James, > > I fully agree with you and understand your statement about -O2. > > Now some questions for you: > Did you try to reproduce experiments described in my previous e-mail ? > Did you look at debug informations generated for 'n' parameter on x86 32-bit > & x86 64-bit ? >

I tried bu clang seems to support only target on which it has been compiled. If I use: with clang -S -emit-llvm t.c -o t.ll I've got following file for t.ll ; ModuleID = 't.c' target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128" target triple =

You can compile an empty C source code with clang -S -emit-llvm and copy the data layout from there. 2011/10/27 Seb <babslachem at gmail.com> > Hi all, > > Can someone give me advice on what should be a good definition of target > datalayout for an ARM cortex-A9 + neon target and x86 32-bit ? > Shall I use a different definition for a cortex-A9 without neon ? > Thanks for

Hi James, clang is able to generate correct debug informations for 64-bit target at -O2. My feeling, given some other experiments I've done, is that debug information generated for x86 32-bit might be broken for parameters as long as they are not 'homed' in the code (local copy to an automatic variable). It seems that when llvm.declare is turned into a llvm.value for parameter there

On Mar 6, 2012, at 5:31 AM, Seb <babslachem at gmail.com> wrote: > Hi all, > > Anyone have ideas/info on this topic ? > Thanks > Seb > > 2012/3/2 Seb <babslachem at gmail.com> > Hi all, > > I'm using my own front-end to generate following code .ll file targeting x86 32-bit: > > ; ModuleID = 'check.c' > target datalayout =

On 29/05/12 15:39, Sebastien DELDON-GNB wrote: > Hi all, > > I was wondering if 'llc' is able to generate 'it' instruction for ARM Cortex-A9 target ? > > Thanks for your answers > Seb > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >