[LLVMdev] fixed point types

[Frits van Bommel]

On Wed, Dec 1, 2010 at 8:11 AM, me22 <me22.ca at gmail.com> wrote:
> On Tue, Nov 30, 2010 at 05:48, Jonas Paulsson <jnspaulsson at hotmail.com> wrote:
>> May I ask then, what could one expect from various optimizations when using
>> intrinsics to support the fixed point type? LTO, Value optimizations, mem ??
>>
>
> Can you not just lower your fixed-point operations to widen, perform
> normal integer operation, shift and truncate?  With LLVM's support for
> arbitrary-width integer types, it might work surprisingly nicely.  For
> instance, a 8.24 multiply would be:
> - widen the i32s to i56s
> - multiply
> - shift right 24
> - truncate to i32

Wouldn't the result of 8.24 * 8.24 be 16.48, requiring widening to i64
instead of i56?

> Then you'd get working code free from LLVM's type legalizer and
> friends, and it would just be up to the backends to recognize the
> possibilities for doing things smarter, if they have relevant
> instructions.  (Just like it is for rotation, etc.)  Optimizations
> would see normal operations they already know how to simplify and
> fold.  And anything special -- like saturating -- would fall out from
> the normal integer operations.

I think saturating might warrant intrinsics, but above transform would
be one of the optimizations I suggested -instcombine might do if it's
provable no saturation can occur.

And yes, I'd definitely suggest pattern-matching the pure-integer
versions in a backend for a target that supports the fixed-point ones
natively if they're more efficient than the expanded versions (i.e.
even if saturation isn't needed). It'd also help catch integer
operations with similar patterns.