[llvm-dev] Complex proposal v3 + roundtable agenda
Steve (Numerics) Canon via llvm-dev
llvm-dev at lists.llvm.org
Fri Dec 4 11:23:51 PST 2020
(Late to the party)
I think there’s a lot of good questions in this thread, but I also want Florian to get started landing some patches and then everyone can iterate on that.
Slight pushback on this one question:
> On Nov 19, 2020, at 18:11, Cameron McInally via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> On Wed, Nov 18, 2020 at 4:47 PM Krzysztof Parzyszek via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>> Complex type would pose another issue for vectorization: in general it's better to have a vector of the real parts and a vector of the imaginary parts for the purpose of arithmetic, than having vectors of complex elements (i.e. real and imaginary parts interleaved).
>
> Is that universally true? I think it depends on the target. Let's take
> Florian's FCMLA example. The inputs and output are interleaved. And if
> you need just the reals/imags from an interleaved vector for something
> else, LD2/ST2 should be pretty fast on recent chips.
FCMLA makes it so _if your data is already interleaved and you can’t change it_, you can still operate efficiently in that format. But if you have control, and you’re doing anything beyond basic arithmetic, it’s still advantageous to use a planar [SoA] layout instead of interleaved [AoS]. For a simple example, if you want to vectorize a complex exponential function, you’ll want to compute cos and sin of the imaginary parts, and exp of the real parts—FCMLA doesn’t help here.
So Florian’s proposal:
> In the short-term I think to get things rolling it would be good to focus on the layout as defined by frontends (e.g. Clang/C++).
Sounds great to me.
– Steve
More information about the llvm-dev
mailing list