[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