<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
<br><br>> Date: Fri, 26 Nov 2010 18:08:53 +0200<br>> From: edwintorok@gmail.com<br>> To: jnspaulsson@hotmail.com<br>> CC: llvmdev@cs.uiuc.edu<br>> Subject: Re: [LLVMdev] LLVMdev Digest, Vol 77, Issue 41<br>> <br>> On Fri, 26 Nov 2010 16:32:42 +0100<br>> Jonas Paulsson <jnspaulsson@hotmail.com> wrote:<br>> <br>> > <br>> > <br>> > <br>> > > On Thu, 25 Nov 2010 11:06:48 +0100<br>> > > Duncan Sands <baldrick@free.fr> wrote:<br>> > > <br>> > > > Hi Jonas,<br>> > > > <br>> > > > > I am investigating the possibilities of incorporating fixed<br>> > > > > point support into the LLVM I/R.<br>> > > > <br>> > > > I think you should write a rationale explaining why you want to<br>> > > > introduce new types etc rather than using the existing integer<br>> > > > types, with intrinsic functions for the operations, or some other<br>> > > > such scheme. Introducing new types is hard work and creates a<br>> > > > maintenance burden for everyone, since they will need to be<br>> > > > properly supported by all parts of the compiler forever more. It<br>> > > > is therefore important to give a cogent explanation of why this<br>> > > > is the best approach, why the benefits outweigh the costs, and so<br>> > > > forth.<br>> > > <br>> > > Also can't fixed point be handled entirely by the frontend?<br>> > > You store the scaling factor as an attribute on the type.<br>> > > <br>> > > When you perform operations that involve the same fixed point types<br>> > > you can perform them with integers, and when you need to perform<br>> > > conversions you emit the appropriate code to perform the<br>> > > conversions. The emitted LLVM IR needs to know nothing about the<br>> > > scaling factors involved.<br>> > > For saturation, etc. you can use the SSE intrinsics.<br>> > > <br>> > > Best regards,<br>> > > --Edwin<br>> > <br>> > Hi again,<br>> > <br>> > thanks for the answers.<br>> > <br>> > Well, the reason DSP compilers would benefit from the new type, is<br>> > that fixed point numbers must not be optimized as integers - eg if<br>> > two saturated fixed point constants would overflow in an addition<br>> > operation, the result should as well be saturated. Doing this in a<br>> > series of steps with intrinsics would be quite ridiculous as far as<br>> > performance goes, because this is _supported by the DSP in hardware_<br>> > in a single instruction :-) <br>> > <br>> > What about perhaps introducing a new type, and allowing just minor<br>> > extensions, while barring it from more heavy scattered code? I mean,<br>> > the GVN pass works by just adding an enum entry and a switch case for<br>> > each new instruction. But in other cases, there are more LOCs<br>> > involved in lifting in new instructions. Then, these passes would be<br>> > left untouched, for the sake of maintainability. These passes could<br>> > be copied for fixed point versions. This would mean a just a little<br>> > slower compiler (dual passes in some cases), for the case of a<br>> > separation of the code that not everywone is interested in. Then,<br>> > these passes could be run just by the DSP targets that need them, and<br>> > the integer developers would not have to worry at all (perhaps by<br>> > explicitly excluding fixed point instructions here and there,<br>> > though). <br>> <br>> Ah now it makes sense: you want the existing optimizations (GVN,<br>> instcombine, reassociation, etc.) applied to arithmetic ops on your<br>> type.<br>> <br>> > <br>> > Another idea is to introduce a scheme of intrinsics and perhaps<br>> > handle optimizations in the backend as much as possible, as a first<br>> > step. If this works well, and interest grows, maybe then the rest<br>> > will follow?<br>> <br>> Yes maybe introducing your own intrinsics as suggested by Duncan<br>> is best. You can lower the intrinsic to your hardware instruction<br>> directly. Optimizers won't know what your intrinsic is, so they would<br>> mostly skip them.<br>> <br>> > <br>> > My point is that there does not seem to be a great open source DSP<br>> > compiler available, yet there is certainly some interest. GCC has<br>> > passes that can handle DSP targets, but it is still not a DSP<br>> > compiler as such, really. I think you have a chance to fill a need<br>> > here which would invite even more people to work on the project. With<br>> > fixed point support, a new DSPTargetMachine could be made which could<br>> > really make a difference in the DSP domain as a _DSP compiler_! I<br>> > have made extensions already - very simple - that seems to work great<br>> > for VLIW scheduling and RA. It would be a pity not to give all this<br>> > serious thought, I'd say.<br>> <br>> Will existing passes keep working after you introduce this new type<br>> (assuming they are run on a module which doesn't make use of the new<br>> type)?<br>> <br>> Best regards,<br>> --Edwin<br><br><pre>Yes, the new type is simply a static object managed by Type and<br>LLVMContext. This is only referred to by Values of fixed point type.<br>New instructions should not interfer with existing passes, as opcodes<br>are switched and handled and would simply continue to be unaware of the<br>new opcodes.<br> <br>My main concern is that code evolution demands following of the LLVM<br>release series of the future. So, even if this got done locally, it<br>would be a hassle to deal with if future releases did not include it at<br>all. So, even if only a small part of it got committed, like say all<br>parts that do not concern or disturb the optimizers - like the type and<br>instructions themselves, this would be better then nothing at all. If<br>then some other party wanted to contribute, this would not lead to<br>enormous merge aches.<br> <br>regards,<br> <br>/Jonas</pre><br> </body>
</html>