[PATCH] D54719: [Intrinsic] Signed Fixed Point Multiplication Intrinsic

[Bjorn Pettersson via Phabricator via llvm-commits]

bjope added a comment.

In https://reviews.llvm.org/D54719#1305550, @leonardchan wrote:

> In https://reviews.llvm.org/D54719#1305542, @craig.topper wrote:
>
> > Do we have examples of real hardware that implements this sort of instruction?
> >
> > Right now this intrinsic looks like its just reimplementing what you would get if you just emitted this IR
> >
> >   %a = sext iX %x to i2X
> >   %b = sext iX %y to i2X
> >   %c = mul i2X %a, %b
> >   %d = lshr i2X %c, PRECISION
> >   %e = trunc i2X %d to iX
> >
> >
> > So I'm not sure if there's a need for an intrinsic unless that pattern is difficult to match to an instruction.
>
>
> I think @ebevhan and @bjope may have hardware with fixed point instructions


Yes, our HW support various kinds of fixed point multiplication (such as `llvm.smul.fix.i32(i32 %x, i32 %y, i32 31)` and `llvm.smul.fix.i24(i24 %x, i24 %y, i32 15)`). We already have an intrinsic like `llvm.smul.fix` downstream.

For our downstream target we keep the intrinsic all the way to ISel. When compiling for other targets we have so far used an IR pass that transform the intrinsic to regular IR early in opt. I'm afraid that if we do that kind of expansion also for our target, we would introduce mul/lshr using non-legal types like i64 or i48. If we can't successfully match the IR back to a native instruction we will get really bad performance by doing the multiplication using the non-legal types. I'm also afraid that the pattern matching easily can be broken, for example by an IR pass that sinks the trunc to a later BB.


Repository:
  rL LLVM

https://reviews.llvm.org/D54719