I am investigating the possibilities of incorporating fixed point support into the LLVM I/R.
So far, I have experimented a bit with defining a new type, adding some instructions and extended some simple cases of optimization. What is needed is a full support of types, instructions and rewriting of optimization passes etc so as to fully incoorporate the type.
We find it important to make this part of future releases, so as to ensure a good software evolution.
We would like to know your view on all this. What would you like to see happen for an inclusion of fixed point support in the near future, in a premise of long term support?
If I were to write the code myself, what would you expect then prior to merging? Any procedure / contacts I should know of?
Are there any developers ready that you know of that are competent with LLVM and willing to do this work in a swift manner?
Master of Science, CS
I am investigating the possibilities of incorporating fixed point support into
the LLVM I/R.
I think you should write a rationale explaining why you want to introduce new
types etc rather than using the existing integer types, with intrinsic functions
for the operations, or some other such scheme. Introducing new types is hard
work and creates a maintenance burden for everyone, since they will need to be
properly supported by all parts of the compiler forever more. It is therefore
important to give a cogent explanation of why this is the best approach, why
the benefits outweigh the costs, and so forth.
Also can't fixed point be handled entirely by the frontend?
You store the scaling factor as an attribute on the type.
When you perform operations that involve the same fixed point types you
can perform them with integers, and when you need to perform
conversions you emit the appropriate code to perform the conversions.
The emitted LLVM IR needs to know nothing about the scaling factors
For saturation, etc. you can use the SSE intrinsics.