<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
Hi, <br><br>thanks a lot for the answer.<br><br>By mem, I meant optimizations that involves load/store intrinsics, eg llvm.fixPload(). What would the consequences of this be?<br><br>I ask then, is there any interest at all in the LLVM community for fixed point support in the future? Are there even any local successful projects that you know of?<br><br>Did you mean that fixed point support in terms of intrinsics and code extensions could become part of the main line?<br><br>Regards,<br><br>Jonas Paulsson<br><br><br><br>> Date: Tue, 30 Nov 2010 15:29:46 +0100<br>> Subject: Re: [LLVMdev] fixed point types<br>> From: fvbommel@gmail.com<br>> To: jnspaulsson@hotmail.com<br>> CC: clattner@apple.com; llvmdev@cs.uiuc.edu<br>> <br>> On Tue, Nov 30, 2010 at 2:48 PM, Jonas Paulsson <jnspaulsson@hotmail.com> wrote:<br>> > all right, no fixed point type in LLVM :-(<br>> ><br>> > May I ask then, what could one expect from various optimizations when using<br>> > intrinsics to support the fixed point type? LTO, Value optimizations, mem ??<br>> <br>> You'd have to implement explicit support for the new intrinsics in<br>> various places. For value optimization, I imagine you'll want to add<br>> support to both lib/Analysis/ConstantFolding.cpp (for when all<br>> arguments are constants) and<br>> lib/Transforms/InstCombine/InstCombineCalls.cpp (for when at least one<br>> isn't).<br>> <br>> LTO support would be automatic since I can't really imagine<br>> -instcombine not running during LTO (unless perhaps inlining is<br>> disabled, in which case it probably won't matter anyway), and that's<br>> just one of the passes that try to constant fold instructions<br>> (including intrinsics calls).<br>> <br>> One "obvious" optimization to add to -instcombine would be to<br>> substitute regular integer operations when it's safe: when there's<br>> provably no overflow that might need to saturate (don't forget to add<br>> nsw/nuw in this case), and no problems regarding whatever else, if<br>> anything, makes these different from "plain old ints".<br>> <br>> The backends would also need support of course, because presumably you<br>> can't *always* simplify them away :).<br>> <br>> I'm not quite sure what you mean by "mem", but if they're marked<br>> appropriately all the optimizers that care will know they don't access<br>> memory (if that's what you meant). This should also allow passes like<br>> GVN to handle them automatically.<br>> <br>> Eventually, you may also want to make some of the analyses and some<br>> other specific transformation passes aware of the semantics of the<br>> intrinsics.<br>> <br>> > Are you saying it is feasible to add intrinsics and some extra optimizers<br>> > for these, then?<br>> <br>> Should be, as long as backend support isn't a problem. And that's a<br>> problem you'd have whether they're designed as intrinsics taking ints<br>> or as new instructions and/or types.<br>> <br>> You probably won't even need new optimization passes; just add some<br>> switch cases to the ones that are already there.<br>> <br>> <br>> Of course, you shouldn't go overboard with the intrinsics; for<br>> example, I imagine that fixed-point types can just use 'icmp' for<br>> comparisons since they're really just scaled integers. So only add the<br>> ones you actually need, if only because it's less work both when<br>> implementing them and when updating the optimizers to support them.<br> </body>
</html>