[LLVMdev] fixed point types

[Frits van Bommel]

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.