[LLVMdev] Embedded C Extensions

[Chris Lattner]

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 doing this work.  Doing so requires at least 
three pieces of work:

1. Merging in the relevant front-end changes into llvm-gcc.
2. Creating LLVM IR operations to represent the new features.
3. Teaching the backend to 'legalize' these away for targets that don't
    support them (i.e. to libcalls or other simple arithmetic ops).

These don't all have to be done in one step of course.  If you're 
interested in this, I'd suggest starting with #2.

>    i see two basic approaches:
>    a) implement fractional and saturated operations using
> (conditional) integer arithmetic.
>       this does not require to change anything within llvm but might
> make it hard to detect
>       those patterns for the instruction selector in order to
> generate efficient code
>       for architectures with hardware support for those features.

Ah, this would be even easier.  If you took this path, you would only need 
#1 above.  The problem is that it would be hard to reconstruct the 
operations at isel time, and the mid-level optimizers couldn't hack on 
these operations as easily.

>    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 
treating these as just new binary operators (e.g. add_fract_sat) which 
take normal integer datatypes (e.g. i32).  LLVM 2.0 is designed to encode 
information about arithmetic ops into the operations instead of the types 
where possible: e.g. we have ashr and lshr instead of signed vs unsigned 
types.

Would this work?

-Chris

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