[LLVMdev] Embedded C Extensions

[Dietmar Ebner]

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

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? this task would also include a mapping of fixed  
point operations to the existing integer infrastructure.

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.

thanks a lot for your comments! greetings,

-
dietmar