[llvm-dev] Complex proposal v3 + roundtable agenda

[Sjoerd Meijer via llvm-dev]

Thanks, and we are happy to pick this up as we are keen to start somewhere with this.

We might for a slightly different approach though: instead of using target independent intrinsics, we are thinking of target dependent intrinsics. I.e., in a CodeGen pass we would like to recognise complex arithmetic and emit target intrinsics for this if the target supports this. The output of the loop/SLP vectorisers seem good enough that we can do this matching in a CodeGen pass and by using target dependent intrinsics avoid the more controversial discussion about introducing target independent intrinsics that other passes then potentially must deal with. Thus, avoid canonicalisation of complex arithmetic in IR, for now. I see that as something complementary to this approach, because if a complex as first-class types/instructions initiative is kicked off that will be a big undertaking that will take some time. In the meantime, we are going to prototype a few things and can give an update here once we know a bit more, and expect that we can support quite a lot of cases with this approach (and we are interested in different targets: MVE, Neon/SVE).

Cheers,
Sjoerd.
________________________________
From: Florian Hahn <florian_hahn at apple.com>
Sent: 04 October 2021 11:16
To: Sjoerd Meijer <Sjoerd.Meijer at arm.com>; llvm-dev <llvm-dev at lists.llvm.org>
Cc: David Greene <greened at obbligato.org>; Steve (Numerics) Canon <scanon at apple.com>; Nicholas Guy <Nicholas.Guy at arm.com>
Subject: Re: [llvm-dev] Complex proposal v3 + roundtable agenda



On Sep 30, 2021, at 14:23, Sjoerd Meijer <Sjoerd.Meijer at arm.com<mailto:Sjoerd.Meijer at arm.com>> wrote:

Hello,

I would like to revive this thread.

We started thinking about supporting complex number support, for the same reason Florian stated in his first mail. The idea before I googled and stumbled on this thread, was the same as Florian proposed. So yes, I would like to support this approach. 🙂 I would like to add that GCC's approach is the same/similar: complex number patterns are recognised in the SLP vectoriser, and complex number builtins are emitted (and then matched later).

Any objections if we go for this approach? Florian, any plans to pick this up?


I still think the intrinsics route is a good way to start and to incrementally improve support for architectures that have dedicated instructions for complex multiply & co relatively quickly. I rebased the patches sketching support for such an intrinsic on AArch64 (https://reviews.llvm.org/D91346 and stacked patches). But I won’t be able to continue lobbying for this approach in the near future. I’d be more than happy if anybody would be interested in picking this up.

Cheers,
Florian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211005/1c00508c/attachment.html>