Hi, 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? Best regards, Jonas Paulsson Master of Science, CS Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101125/e1b7faba/attachment.html>
Hi Jonas,> 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. Ciao, Duncan.
On Thu, 25 Nov 2010 11:06:48 +0100 Duncan Sands <baldrick at free.fr> wrote:> Hi Jonas, > > > 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 involved. For saturation, etc. you can use the SSE intrinsics. Best regards, --Edwin