similar to: [LLVMdev] troubles with llvm-gcc 4.0 and APFloat on X86_64

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

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

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,

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

On Oct 22, 2007, at 12:25 PM, Dietmar Ebner wrote: > 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

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

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 consumer device suitable for developing and testing HLVM on, rather than using a cross compiler and

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

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

Dietmar, > this fixes single precision floating point but breaks double precision. > for arm-softfloat-linux-gnu, FLOAT_WORDS_BIG_ENDIAN is true while > WORDS_BIG_ENDIAN is false. as far as i've seen, there's only a single > flag for endianess in the llvm target description string, so i don't > really understand how this is supposed to work. Hrm, I think I even

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

hello, upgrading llvm-gcc4 from 1.9 release to trunk caused the following build failure for me on darwin: build/genattrtab /Users/ebner/dev/opt/llvm-gcc-svn/gcc/config/i386/ i386.md > tmp-attrtab.c genattrtab: Automaton `ppro_load': Insn `ppro_fmov_XF_load' will never be issued genattrtab: Automaton `ppro_load': Insn `ppro_sse_icvt_SF' will never be issued genattrtab:

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

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, we're considering LLVM as an excellent framework for a compiler backend for a novel dsp architecture based on vliw principles that is still under development. in this context, two students at our institute are particularly interested in the following projects: I) software pipelining apparently [1], there has been already an remarkable amount of work done by tanya lattner