[LLVMdev] Embedded C Extensions
ebner at complang.tuwien.ac.at
Wed Feb 14 04:33:19 PST 2007
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
> data types whose operators have special semantics. As such, I'd
> 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
> information about arithmetic ops into the operations instead of the
> where possible: e.g. we have ashr and lshr instead of signed vs
> 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,
More information about the llvm-dev