[LLVMdev] fixed point types

[Jonas Paulsson]

Hi, 

thanks a lot for the answer.

By mem, I meant optimizations that involves load/store intrinsics, eg llvm.fixPload(). What would the consequences of this be?

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?

Did you mean that fixed point support in terms of intrinsics and code extensions could become part of the main line?

Regards,

Jonas Paulsson



> Date: Tue, 30 Nov 2010 15:29:46 +0100
> Subject: Re: [LLVMdev] fixed point types
> From: fvbommel at gmail.com
> To: jnspaulsson at hotmail.com
> CC: clattner at apple.com; llvmdev at cs.uiuc.edu
> 
> On Tue, Nov 30, 2010 at 2:48 PM, Jonas Paulsson <jnspaulsson at hotmail.com> wrote:
> > all right, no fixed point type in LLVM :-(
> >
> > May I ask then, what could one expect from various optimizations when using
> > intrinsics to support the fixed point type? LTO, Value optimizations, mem ??
> 
> You'd have to implement explicit support for the new intrinsics in
> various places. For value optimization, I imagine you'll want to add
> support to both lib/Analysis/ConstantFolding.cpp (for when all
> arguments are constants) and
> lib/Transforms/InstCombine/InstCombineCalls.cpp (for when at least one
> isn't).
> 
> LTO support would be automatic since I can't really imagine
> -instcombine not running during LTO (unless perhaps inlining is
> disabled, in which case it probably won't matter anyway), and that's
> just one of the passes that try to constant fold instructions
> (including intrinsics calls).
> 
> One "obvious" optimization to add to -instcombine would be to
> substitute regular integer operations when it's safe: when there's
> provably no overflow that might need to saturate (don't forget to add
> nsw/nuw in this case), and no problems regarding whatever else, if
> anything, makes these different from "plain old ints".
> 
> The backends would also need support of course, because presumably you
> can't *always* simplify them away :).
> 
> I'm not quite sure what you mean by "mem", but if they're marked
> appropriately all the optimizers that care will know they don't access
> memory (if that's what you meant). This should also allow passes like
> GVN to handle them automatically.
> 
> Eventually, you may also want to make some of the analyses and some
> other specific transformation passes aware of the semantics of the
> intrinsics.
> 
> > Are you saying it is feasible to add intrinsics and some extra optimizers
> > for these, then?
> 
> Should be, as long as backend support isn't a problem. And that's a
> problem you'd have whether they're designed as intrinsics taking ints
> or as new instructions and/or types.
> 
> You probably won't even need new optimization passes; just add some
> switch cases to the ones that are already there.
> 
> 
> Of course, you shouldn't go overboard with the intrinsics; for
> example, I imagine that fixed-point types can just use 'icmp' for
> comparisons since they're really just scaled integers. So only add the
> ones you actually need, if only because it's less work both when
> implementing them and when updating the optimizers to support them.
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101201/730137ef/attachment.html>