[PATCH] D117480: [IR] Extend llvm.vector.reduce.fadd

Mon Jan 17 07:53:08 PST 2022

fhahn added a comment.

In D117480#3248549 <https://reviews.llvm.org/D117480#3248549>, @nikic wrote:

> In D117480#3248511 <https://reviews.llvm.org/D117480#3248511>, @fhahn wrote:
>
>> `reassoc` implies 'any order', but in some cases it is desirable to specify a specific order, e.g. for the vector reduction builtin provided by Clang.
>
> Are we following someone else's standard here, or can we specify the behavior? If a specific reduction order is required, I would very much expect that to be "ordered reduction".
>
> I'm not a fan of introducing a third order here if we can avoid it. The value of having something other than ordered/unordered is not clear to me.

I assume ordered here means sequential. The clang builtin specifies a tree-wise reduction order. The main motivation for that order is to enable faster execution and consistent results on different HW architectures. At the moment the existing intrinsic is either slow & consistent or fast & inconsistent.

> I'm not convinced about all this implied complexity.
> I think clang will just have to emit expanded form of the reduction in that case.

Sure it could, but it seems unfortunate that a common reduction pattern cannot be expressed with the reduction intrinsic. The main benefit of using the reduction intrinsic here is to make instruction selection substantially easier. AFAICT the main complexity will be in the backends, which will now have to be able to deal with the new order. But given that at the moment only AArch64 and RISCV, it should't be too bad?

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D117480/new/

https://reviews.llvm.org/D117480