llvm dev - Dec 2010 - [LLVMdev] fixed point types

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.

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>

On Wed, Dec 1, 2010 at 8:25 AM, Jonas Paulsson <jnspaulsson at
hotmail.com> wrote:
> By mem, I meant optimizations that involves load/store intrinsics, eg
> llvm.fixPload(). What would the consequences of this be?
Since the proposed intrinsics would operate on regular integer types,
why can't you just use regular load and store instructions?
> Did you mean that fixed point support in terms of intrinsics and code
> extensions could become part of the main line?
If someone implements the intrinsics and they are useful on at least
one target that main line supports, I don't see why those patches
would be rejected. Especially since Chris seems to be on board :).