similar to: [LLVMdev] predicated execution

On Mar 7, 2007, at 6:45 AM, Dietmar Ebner wrote: > 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. Ok. > a

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 Mar 31, 2008, at 2:37 AM, Dietmar Ebner wrote: > 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

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

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

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

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

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

Pertti, On Feb 13, 2007, at 7:34 PM, Pertti Kellomäki wrote: > Dietmar Ebner wrote: >> most of the work seems to be done in an architecture dependent, >> very low- >> level IR. are there any efforts to generalize architecture >> independent portions >> of the code. >> any comments on this are very appreciated. > > We are in a similar

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

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

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:

There is an opening for two post-docs and one PhD position in the field of optimal code generation techniques for explicit parallel processors at the Vienna University of Technology. We seek people familiar with LLVM and/or with some background of integer linear programming and VLIW code generation. If interested, please respond directly to Andreas Krall: andi at complang.tuwien.ac.at

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

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