similar to: [LLVMdev] LLC ARM Backend maintainer

On 10/17/2011 09:20 AM, Pawel Wodnicki wrote: > > My first ARM testing results or lack of them indicate > that 3.0 release requires some some beefy machines to build. > It is not so much raw cpu speed but memory and lots of it. > My builds got to linking llc and at that point linker started > eating megabytes of memory like chocolate. > > So sadly chumbys, beagleboards,

Also, was this with binutils-gold? -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Tobias Grosser Sent: 17 October 2011 09:56 To: Pawel Wodnicki Cc: llvmdev Subject: Re: [LLVMdev] LLC ARM Backend maintainer On 10/17/2011 09:20 AM, Pawel Wodnicki wrote: > > My first ARM testing results or lack of them indicate > that

On Thu, Oct 13, 2011 at 10:00 AM, Joe Abbey <jabbey at arxan.com> wrote: > However, we don't have testing resources to test both our product and LLVM > on a host of target boards.  We have some chumbys, beagleboards, iPhones, > iPod Touches, tables, Android Phones, etc.  And most of those are already > booked solid with our own regression tests (most of which are based on

Admittedly we're very interested in becoming ARM backend maintainers as our product heavily relies on LLVM. However, we don't have testing resources to test both our product and LLVM on a host of target boards. We have some chumbys, beagleboards, iPhones, iPod Touches, tables, Android Phones, etc. And most of those are already booked solid with our own regression tests (most of which

> The ARM Holdings emulator does this; I used it with great success to > profile an Advanced Encryption Standard encryptor a while back. It is indeed a useful piece of kit. We do a lot of our internal regression tests on it, and also run LLVM's regression tests every night on it (as well as PlumHall, EEMBC and SpecInt). Unfortunately it's not exactly software we can give away or

Evan, > I'm the code owner of LLVM codegen and targets. I'm also the one of main developers on the original ARM target. That means, I would make the decisions on major development on ARM target if there are decisions to be made. > > But my role is very different from what people are looking for in this thread. To properly qualify a target like ARM which are supported on many

Well how about as a strawman... taking some options from http://en.wikipedia.org/wiki/List_of_ARM_microprocessor_cores and http://en.wikipedia.org/wiki/List_of_applications_of_ARM_cores LLVM Supports: ARMv4T -> ARM7TDMI ARMv5TE -> ARM926EJ-S -> XScale ARMv6 -> ARM1136J(F)-S ARMv6ZK -> ARM1176JZ(F)-S ARMv7A -> Cortex-A8 Cortex-A9 ARMv7M -> Cortex-M3

I think we need a group of maintainers rather than a single maintainer given the spectrum of ARM targets/ISAs/platforms required to support and the amount of people/system resources required. I & my team plan to actively participate in the bug-fixing process during the release cycle. If we can divide the bugs among the maintainers and establish a requirement that all open ARM bugs must be

I'm the code owner of LLVM codegen and targets. I'm also the one of main developers on the original ARM target. That means, I would make the decisions on major development on ARM target if there are decisions to be made. But my role is very different from what people are looking for in this thread. To properly qualify a target like ARM which are supported on many different CPUs and

I see, so perhaps the LLVM ARM Backend is in need of a method of organizing volunteer qualifiers, as releases near? Has this generally been organized via this mailing list? Joe Joe Abbey Software Architect Arxan Technologies, Inc. 1305 Cumberland Ave, Ste 215 West Lafayette, IN 47906 W: 765-889-4756 x2 C: 765-464-9893 jabbey at arxan.com<mailto:jabbey at arxan.com>

On Oct 13, 2011, at 10:33 AM, Raja Venkateswaran wrote: > I think we need a group of maintainers rather than a single maintainer given the spectrum of ARM targets/ISAs/platforms required to support and the amount of people/system resources required. I & my team plan to actively participate in the bug-fixing process during the release cycle. If we can divide the bugs among the maintainers

So, I just got my GumStix Stuart BT today: http://www.gumstix.com For a non-telephony (Bluetooth based) project. I'm browsing the SVN website for Gumstix and lo and behold, there is Asterisk! I'm excited. Has anyone ever tried it on a GumStix before, and if so, care to share tips? If anybody is curious, this is a PC the size of 2 packs of Wrigley's Spearmint Gum put together. Runs

It would be a real kick to get one of these to run Asterisk. :) http://www.gumstix.com/ Tim -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >>

On 11 October 2011 18:22, Anton Korobeynikov <anton at korobeynikov.info> wrote: > 1. We should define which ARM-related features (in general, e.g. > platforms, cores, modes, etc.) we consider "release important" > 2. We should define the conditions how the features in 1. should be tested > 3. Someone should perform such testing for each release, provide help > with

Hi James, > It goes without saying that I +1 this. Well, the answer should be pretty easy, I think: 1. We should define which ARM-related features (in general, e.g. platforms, cores, modes, etc.) we consider "release important" 2. We should define the conditions how the features in 1. should be tested 3. Someone should perform such testing for each release, provide help with

On 3/27/11 4:38 AM, Bill Wendling wrote: > Hi all, > Please check out sources. Compile things. Report bugs. Etc. I'm not sure if this is useful as is, but attached is output of `make check` for llvm+clang, on a Tegra2 machine with ubuntu linux. The ocaml binding failures are due to the fact there is no ocamlopt on arm, even though there is ocaml/ocamlc, and the bindings compile

On 3 January 2013 22:09, Nadav Rotem <nrotem at apple.com> wrote: > The loop vectorizer is now enabled by default. > I thought that was just a temporary arrangement to get the feel for it, not to actually have it on all the time (next release). Is it just for -O3 or lower too? This can cause problems, for instance on ARMv7, the default is that NEON is present, but Tegra2 doesn't

On Thu, Oct 13, 2011 at 11:25 AM, Joe Abbey <jabbey at arxan.com> wrote: > LLVM Supports: > ARMv4T  -> ARM7TDMI > ARMv5TE -> ARM926EJ-S >         -> XScale > ARMv6   -> ARM1136J(F)-S > ARMv6ZK -> ARM1176JZ(F)-S > ARMv7A  -> Cortex-A8 >            Cortex-A9 > ARMv7M  -> Cortex-M3 Does the LLVM code generator generate Thumb code in addition to

I'm working on a couple of Yocto Project based embedded projects, one using a Gumstix Overo board and the other using an Intel Atom motherboard. Both need a simple Samba server, which isn't included in the standard build. The only existing Yocto-compatible recipe for Samba is an OpenEmbedded one for version 3.6.8. I was quite surprised to find that adding Samba almost tripled the size of

>"When you say boards with OGL ES graphics chips come with the drivers in them, do you mean the OGL ES driver is inside the graphics chip?" inside box.. on CD or floppy :-) ____________________________ you got right to the point there actually, drivers do belong in hardware, if you ask me... i just fail to see why not we already do have pixel/vertex shaders, which is, roughly