search for: tegra2

...e 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, iThingis(?), Raspberry Pis, Gumstix and even inexpensive Tegra2 boards seem to be out of contention and relegated to target testing. Based on my observations minimum memory required to build LLVM-3.0 seems to be 768MB to 1GB of RAM plus a 1.2+ GB of free disk space for one kind of build. NVIDIA has some tegra2 boards with 1GB but for their prices one can get...

...chines 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, iThingis(?), Raspberry Pis, Gumstix > and even inexpensive Tegra2 boards seem to be out of contention > and relegated to target testing. > > Based on my observations minimum memory required to build LLVM-3.0 > seems to be 768MB to 1GB of RAM plus a 1.2+ GB of free disk space > for one kind of build. > > NVIDIA has some tegra2 boards with 1GB...

Samsung Enterprise Portal mySingle We have release a reference code for a para-virtualized linux kernel. You will find it on "git://xenbits.xen.org/people/jm77ryu/linux-xen.git" In case of xen-arm source, please visit to "git://xenbits.xen.org/people/jm77ryu/xen-arm.git" - Build Instructions: - 1. extract root filesytem contents as following(This requires the root

...chines 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, iThingis(?), Raspberry Pis, Gumstix > and even inexpensive Tegra2 boards seem to be out of contention > and relegated to target testing. > > Based on my observations minimum memory required to build LLVM-3.0 > seems to be 768MB to 1GB of RAM plus a 1.2+ GB of free disk space > for one kind of build. > > NVIDIA has some tegra2 boards with 1GB...

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 just fine. For the others, I don't know what they are about at all. -- Mikko Lehtonen -------------- next part --------------...

...e release manager to gather a group of volunteered. These are the folks who are responsible for qualification the targets of their interests on their preferred platform. > > Evan Group of volunteers sounds great! I would like to add my resources for ARM target qualification. - Cortex-A9MP (Tegra2) ARMv7 architecture on Ubuntu/Linux, this is quite useable dual-core system for host testing. I have 2 systems that I can volunteer. - Cortex-A8 I have bunch of devices but they are only good for target testing. - Cortex-Mx ARMv7M I have myriad of boards that I use for target testing, the problem...

Hi all, The good news: RC2 testing was successful in that it uncovered a bad regression from 2.8 (which existed in top-of-tree). It also showed that there was an unincorporated fix that needed to go into the clang branch. The bad news: I'm truncating the RC2 testing phase and announcing the RC3 testing phase. Hopefully, because we caught the bugs in time this phase won't impact 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 have NEON, only VFP. It means an optimizing compilation that used to work on it will fail, unless you specify no NEON or no vectorization explicitly, no? I'd prefer if -vectorization had to be passed explicitly to get it done on production releases of LLVM or something else (-O4 or...

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

On 3 January 2013 21:53, Nadav Rotem <nrotem at apple.com> wrote: > > I am asking this because I would like to have loop vectorization > disabled for targets that don't support SIMD instructions (for example, > standard mips32). > > Loop vectorization bloats the code size and prolongs compilation time > without any improvement to performance for such targets. >

On Jan 3, 2013, at 2:05 PM, Renato Golin <renato.golin at linaro.org> wrote: > Isn't the vectorizer disabled by default? The loop vectorizer is now enabled by default. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130103/4645b2e8/attachment.html>

...nable it as soon as possible in order to catch performance regressions as soon as possible. The vectorizer is currently enabled by default on O2 and O3, and it runs with reduced functionality on Os. > > This can cause problems, for instance on ARMv7, the default is that NEON is present, but Tegra2 doesn't have NEON, only VFP. It means an optimizing compilation that used to work on it will fail, unless you specify no NEON or no vectorization explicitly, no? At the moment ARM does not have a good cost model. It relies on the default implementation which uses the TargetLoweing information...

...hooked to this values. Use: So, the biggest problem we have today in the LLVM back-end is that it assumes too much. If given ARMv7A, it assumes A8+NEON, which is not always true. Even if given Cortex-A8 or A9 specifically, it still assumes NEON, which again, is not 1 to 1. For instance, the new Tegra2 boards sport an A9 without NEON. LLVM generated code would probably break on them. While putting a special case for Tegra2 would work, in ARM world, there are more exceptions than rules, so that's not the optimal solution. The ARM back-end doesn't print ".fpu" in the ASM file. GA...

Hi Renato, everyone On Sat, Nov 13, 2010 at 2:17 PM, Renato Golin <renato.golin at arm.com> wrote: > On 13 November 2010 21:15, Duncan Sands <baldrick at free.fr> wrote: >> Since I don't know anything about these attributes, talk of indexes and >> so forth goes straight over my head. > > Hi Duncan, > > I assumed you knew what build attributes were in the

On Mon, May 26, 2014 at 5:02 PM, Alexandre Courbot <gnurou at gmail.com> wrote: > On Mon, May 26, 2014 at 6:21 PM, Lucas Stach <l.stach at pengutronix.de> wrote: >> Am Montag, den 26.05.2014, 09:45 +0300 schrieb Terje Bergstr?m: >>> On 23.05.2014 17:40, Alex Courbot wrote: >>> > On 05/23/2014 06:59 PM, Lucas Stach wrote: >>> > So after checking