similar to: [LLVMdev] Software Pipelineing | Embedded C Extensions

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

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 situation, with an architecture in our hands that needs software pipelining support. Since SW pipelining is by its very

On Tue, 13 Feb 2007, Dietmar Ebner wrote: > II) Embedded C Extensions [2,3] > there's a ongoing project in gcc [4] that aims to implement > embedded c extensions > for gcc. it appears that the portions belonging to the frontend > are already pretty > stable. are there already people working on getting those bits > into llvm? Nope, I'm not aware of anyone

On Feb 14, 2007, at 2:18 AM, Dietmar Ebner wrote: > 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.

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

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

Dear Chris, On Feb 14, 2007, at 12:33 AM, Chris Lattner wrote: >> b) introduce new types for llvm that handle types such as >> __Fract, __Accum and _Sat. >> again, comments are highly appreciated. > > My understanding of these operations is that they are basically > integer > data types whose operators have special semantics. As such, I'd > suggest

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

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

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

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

> I) software pipelining > apparently [1], there has been already an remarkable amount of > work done > by tanya lattner for the sparc backend. however, it appears it > did not (yet) > make its way into llvm. are there ongoing efforts in this > direction? most of Unfortunately the work was done on the previous sparc backend that did not use the target independent

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, 18 Jun 2007, Chris Lattner wrote: > On Thu, 14 Jun 2007, Dietmar Ebner wrote: >> currently, the DAGCombiner unconditionally converts >> (DAGCombiner::visit(U|S)REM) expressions of the form X % C for constants >> C into X-X/C*C. this makes sense in certain cases where the div/mul >> logic will simplify X/C*X but is counterproductive in general, >>

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,