[llvm-dev] Complex proposal v3 + roundtable agenda

[Florian Hahn via llvm-dev]

> On Nov 12, 2020, at 21:36, Cameron McInally <cameron.mcinally at nyu.edu> wrote:
> 
> On Thu, Nov 12, 2020 at 2:47 PM Florian Hahn <florian_hahn at apple.com <mailto:florian_hahn at apple.com>> wrote:
>> 
>> There certainly is some pieces around the edges that will need adjusting or become obsolete, but I would hope/expect the majority of the work to be re-usable.
>> 
>> As for getting the usual algebraic simplifications for free, even with a new type I suppose we would have to teach instcombine/InstructionSimplify about them. This is indeed an area where a dedicated type is probably quite a bit easier to deal with. But I think part of the vector-predication proposal includes some generic matchers for the different intrinsic, which should be relatively straight-forward to update as well.
> 
> Yes, the IR passes are where I see complex types win. For example,
> pretty much all of InstCombine's visitFMul(...) transformations should
> not depend on type.*** So there's no need to duplicate all that code
> for @llvm.complex.multiply.
> 
> It's true that teaching the pattern matcher to recognize intrinsics
> gets us a long way. But we'd also need to update IR passes in places
> where the Opcode is explicitly checked. E.g.:
> 
> ```
>  switch (Opcode) {
>  <snipped>
>  case Instruction::FAdd: <== ***HERE***
>    return SimplifyFAddInst(LHS, RHS, FastMathFlags(), Q, MaxRecurse);
> ```
> 
> And when a transformation succeeds, we'd need to update how the result
> is returned. E.g.:
> 
> ```
>  // (-X) + Y --> Y - X
>  Value *X, *Y;
>  if (match(&I, m_c_FAdd(m_FNeg(m_Value(X)), m_Value(Y))))
>    return BinaryOperator::CreateFSubFMF(Y, X, &I); <== ***HERE***
> ```
> 
> Both of those come for free with a complex type, along with the
> pattern matching code.
> 

Thanks for expanding on this! I think for InstructionSimplify it should be fairly easy to treat @llvm.complex.multiply & co as their instruction counter parts. InstCombine (or other passes that create new instructions as they combine) will require more additional changes.

This is certainly a trade-off compared to adding dedicated types. But I given the additional complexity and overhead adding new types entails, I think the intrinsics are a good alternative that can get us quite far, especially if we can re-use/build on some of the techniques Simon mentioned.

> I'm not opposed to finding solutions for these problems, but this
> pitch has been around for a while now, and it hasn't really taken off
> yet. It's hard to rally behind it again.

If there’s been an earlier discussion about introducing a small set of intrinsics, I think I missed that. The references linked from the complex type proposal seem to all focus on adding a new type.

> 
> (***) Let me point out that my number theory and abstract algebra are
> *rusty*. So don't be fooled into thinking my initial assumptions about
> complex numbers are correct.
> 
> 
>> I’ll admit that the scope of my pitch is much more limited than the original proposal and very focused on allowing LLVM to use specialized instructions. But it should be relatively simple to implement (without impacting anything unrelated to the passes/backends that are adjusted) and easy to extend to meet additional needs by other people & backends. It also allows to reuse the existing instructions for insert/extract/shuffles and the corresponding folds.
> 
> Generating the special instructions is good, but not if it costs other
> optimizations. Let's get both. :D
> 
> But in all seriousness, my opinion on this topic has hit stark
> resistance before. I won't harp on it if others don't feel the same.
> It's just pretty clear to me that experimental intrinsics are a major
> hurdle to performant code for larger projects.

That’s an interesting point. I am expecting to get most benefits in terms of performance from better vectorizing complex math by using specialized hardware instructions and would expect benefits from better combines to be smaller. But besides reports from our users, I do not have anything to back this up and I suppose this highly depends on the particulars of the codebases.

As discussed earlier, the intrinsics pitch comes with some trade-offs when it comes to re-using existing combines and simplifications. But the key benefit I see is that it is much more lightweight (and hence hopefully easier to get started with) and gives us a path forward to make incremental and noticeable improvements in a relatively short time-span. Even if that doesn’t get us to a perfect state directly, it should make it much easier to start moving in the right direction. And once we hit the point at which we really need dedicated types we already laid much of the ground work with the intrinsics.

Cheers,
Florian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201113/08e8098b/attachment.html>