similar to: [LLVMdev] Consumer ARM platform suitable for LLVM development?

On Wed, Mar 11, 2009 at 3:21 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > Now that I have HLVM up and running on x86 and x64 I am interested in > testing > it out on an ARM in preparation for their imminent world domination. I > believe LLVM already has excellent support for the ARM thanks to Apple's > ARM-based products. However, I'd really like an ARM-based

On Mar 11, 2009, at 9:44 PM, Misha Brukman wrote: > The problem I've had is building an LLVM cross-compiler from Linux/ > x86 to Linux/ARM (as has another llvm-dev poster). Someone > mentioned to me off-list that he managed to get it to build, but I > haven't been able to reproduce the build using his instructions > (I'll post my results in another thread).

On Thu, Mar 12, 2009 at 6:17 AM, Dietmar Ebner <ebner at complang.tuwien.ac.at>wrote: > On Mar 11, 2009, at 9:44 PM, Misha Brukman wrote: > > The problem I've had is building an LLVM cross-compiler from Linux/ > > x86 to Linux/ARM (as has another llvm-dev poster). Someone > > mentioned to me off-list that he managed to get it to build, but I > > haven't

Attached is the patch I've been building arm-eabi with, which might help with linux-gnueabi. I disable multilib to get around several bugs with thumb. I build cross binutils first, then llvm, then llvm-gcc with newlib merged in. The following bugs need to be addressed for these non-Darwin ARM targets: 1388 2313 2545 2985 deep On Fri, Mar 13, 2009 at 12:30 AM, Misha Brukman <brukman at

Can someone with llvm-gcc/ARM expertise (Dale?) please review Sandeep's patch? The patch works for me in building an LLVM-based cross-compiler from x86_64/Linux to ARM/Linux. I have been able to build without the patch to the asm file, but several people have reported needing the asm patch on http://llvm.org/PR2545 . On Thu, Mar 12, 2009 at 8:39 PM, Sandeep Patel <deeppatel1987 at

hi, Dale Johannesen wrote: > On Oct 19, 2007, at 7:23 AM, Dietmar Ebner wrote: >> i'm trying to make some experiments with the ARM backend (llvm 2.1) >> and >> therefore built an arm-softfloat-linux-gnu toolchain on x86_64 linux. >> >> however, the llvm-gcc frontend seems to cause troubles with single >> precision floating point values, i.e., they are

On Mon, 22 Oct 2007, Dale Johannesen wrote: > In principle I think keeping IEEE float and double in an endian- > independent form in the IR files is a good idea. BUT: I'm told > retaining the ability to use files in the existing format is a > requirement (so floats still need to occupy 8 bytes). Since ARM target > doesn't currently work that one is a reasonable

hi, i'm trying to make some experiments with the ARM backend (llvm 2.1) and therefore built an arm-softfloat-linux-gnu toolchain on x86_64 linux. however, the llvm-gcc frontend seems to cause troubles with single precision floating point values, i.e., they are not converted correctly to the particular target format (double precision works as expected). it seems the problem is related to

Chris, Chris Lattner wrote: > I would love to see any progress in this area. It is clearly an > important thing to tackle, and it is blocking other interesting > improvements in the code generator. It would also allow us to > eliminate a significant amount of weirdness that exists to hack around > this (e.g. switch lowering). we've been working on a whole-function

On Mar 25, 2008, at 9:40 AM, Dietmar Ebner wrote: > Chris, > > Chris Lattner wrote: >> I would love to see any progress in this area. It is clearly an >> important thing to tackle, and it is blocking other interesting >> improvements in the code generator. It would also allow us to >> eliminate a significant amount of weirdness that exists to hack >>

Evan Cheng wrote: > That's unfortunate. What kind of licensing issues are there? i've talked to our supporting company and they agreed to release the code to interested parties. it's not a copyleft license but the code can be used freely for private and research purposes. be warned that the code is merely a prototype implementation and not ready for inclusion in LLVM. it also

On Oct 22, 2007, at 2:08 AM, Dietmar Ebner wrote: > hi, > > i've got some more things to note. first, the issue is not related to > x86_64 being the host machine - it also happens on i686/linux. > > next, i think (one of) the problem(s) is the use of > [HOST_]WORDS_BIG_ENDIAN instead of [HOST_]FLOAT_WORDS_BIG_ENDIAN in > llvm-convert.cpp (see patch below). > >

On Oct 19, 2007, at 7:23 AM, Dietmar Ebner wrote: > hi, > > i'm trying to make some experiments with the ARM backend (llvm 2.1) > and > therefore built an arm-softfloat-linux-gnu toolchain on x86_64 linux. > > however, the llvm-gcc frontend seems to cause troubles with single > precision floating point values, i.e., they are not converted > correctly > to the

hi, i've got some more things to note. first, the issue is not related to x86_64 being the host machine - it also happens on i686/linux. next, i think (one of) the problem(s) is the use of [HOST_]WORDS_BIG_ENDIAN instead of [HOST_]FLOAT_WORDS_BIG_ENDIAN in llvm-convert.cpp (see patch below). this fixes single precision floating point but breaks double precision. for

On Mar 18, 2009, at 11:30 AMPDT, Misha Brukman wrote: > Can someone with llvm-gcc/ARM expertise (Dale?) please review > Sandeep's patch? The patch works for me in building an LLVM-based > cross-compiler from x86_64/Linux to ARM/Linux. > I have been able to build without the patch to the asm file, but > several people have reported needing the asm patch on

Dale Johannesen wrote: > On Oct 22, 2007, at 2:08 AM, Dietmar Ebner wrote: >> next, i think (one of) the problem(s) is the use of >> [HOST_]WORDS_BIG_ENDIAN instead of [HOST_]FLOAT_WORDS_BIG_ENDIAN in >> llvm-convert.cpp (see patch below). >> >> this fixes single precision floating point but breaks double >> precision. >> for arm-softfloat-linux-gnu,

hi, we're trying to come up with a static compiler based on llvm for a 4- way vliw architecture with full support for predicated execution. a distinguishing feature is the omission of flag registers. instead, conditions can be paired with a particular instruction within the same bundle. a performance critical issue will be proper use of predicated execution. if-conversion can either

Hello all, I would like to participate in this year's Google Summer of Code and I am sending you a short description of my proposal. I have written the formal proposal already and if someone is interested I can send him the pdf. One of the open projects in the LLVM list is to enhance LLVM with static profiling capabilities. LLVM already provides a unified structure for writing pro

On Mar 24, 2008, at 10:47 PM, Christopher Lamb wrote: > I know that this has been discussed (at least in passing) a few > times on the list, but I couldn't locate a bug for it. Have any > architectural plans been made for it? Funny you bring this up. Evan and I were tossing around crazy ideas about this just today. If you're interested, maybe we should get together for

I know that this has been discussed (at least in passing) a few times on the list, but I couldn't locate a bug for it. Have any architectural plans been made for it? Are there architectural roadblocks with the current LLVM infrastructure that will complicate the process? What has demotivated the implementation of this so far (is it not that big a benefit on important targets, too