[llvm-dev] Complex proposal v3 + roundtable agenda

[Florian Hahn via llvm-dev]

> On 16 Nov 2020, at 16:37, Cameron McInally <cameron.mcinally at nyu.edu> wrote:
> 
> On Fri, Nov 13, 2020 at 3:01 PM Florian Hahn <florian_hahn at apple.com <mailto:florian_hahn at apple.com>> wrote:
>> 
>> 
>> 
>> 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> 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.
> 
> Sorry, I wasn't clear. I meant the pitch to optimize experimental
> intrinsics in general. That general plan to optimize experimental
> intrinsics has been around since the constrained FP intrinsics project
> started. Probably 2016 or 2017.

Oh I see, thanks for the pointers! Constraint FP support is another interesting example.

Cheers,
Florian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201118/3a07a9a9/attachment.html>