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 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. Hoping there isn't some really obvious reason that would fail, ~ Scott
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 i32Wouldn'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.
On Wed, Dec 1, 2010 at 01:46, Frits van Bommel <fvbommel at gmail.com> wrote:> > Wouldn't the result of 8.24 * 8.24 be 16.48, requiring widening to i64 > instead of i56? >It could be, but since i32 * i32 in LLVM gives an i32, not an i64, I thought this was more consistent, as the "i8.24" * "i8.24" would be an "i8.24". It also means that if the multiplication saturates, it gives the right answer -- if you widened to i64, did the saturating multiplication, and truncated, the fixed-point multiply wouldn't have been saturated.> > 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. >I was thinking of saturating as a flag on the instruction, like the current nsw and nuw. Whether they should be that, intrinsics, or new instructions is a decision for people with far more LLVM experience than mine, though.