[LLVMdev] Embedded C Extensions

Chris Lattner sabre at nondot.org
Thu Feb 15 01:01:36 PST 2007


On Wed, 14 Feb 2007, Dietmar Ebner wrote:
>> Would this work?
> probably, though i'm not yet certain. we're considering splitting the
> project in two while one subtask is to catch up with the new gcc
> frontend and the other one is to extend llvm with fixed point
> operations in order to generate efficient code for dsp targets.

ok

> in the first step, we either have to backport the changes in the gcc
> frontend or port llvm-gcc to a more recent version (with the 4.2
> release on its way, this might be a good candidate). it appears,
> resources are better spent for latter. are there major concerns
> speaking against this approach? does anybody have a rough estimate of
> the required effort?

llvm-gcc is mostly affected by changes in the GCC trees.  From my initial 
investigation, it looks like there are a few minor changes (e.g. 
CONSTRUCTOR nodes are a bit different) but nothing major.  It may be 
possible to get a prototype 4.2-merged compiler up in a few weeks.

My group has plans to eventually merge the apple gcc 4.2 compiler work 
into llvm-gcc.  This would sync the front-end with 4.2 and provide several 
other features contributed by apple (most of which may not be interesting 
to people on non-darwin platforms though).  Unfortunately, we don't have a 
definite timespan for this.  We'll most likely pick up this project in the 
next 3-4 months.  This may or may not be too late for you.

> this task would also include a mapping of fixed
> point operations to the existing integer infrastructure.

Right.  That would be new work.

> i doubt that it is feasible matching those complex patterns at
> instruction selection time - considering that optimization passes are
> free to transform the generated code sequences. therefore, i think
> it's best to extend the virtual machine accordingly and add
> corresponding patterns to the backend. i don't know yet how those
> extensions should look like. once we reach this point, we'll try to
> come up with a feasible proposal and ask for comments.

Sounds good.  Another alternative is to add a bunch of intrinsics to 
represent the operations you want.  This is much easier than extending the 
IR, and may be a good starting point for you.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/



More information about the llvm-dev mailing list