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

Mon Jan 17 07:08:28 PST 2022

nikic added a comment.

In D117480#3248511 <https://reviews.llvm.org/D117480#3248511>, @fhahn wrote:

> In D117480#3248421 <https://reviews.llvm.org/D117480#3248421>, @nikic wrote:
>
>> I don't get this change. We already use reassoc FMF to allow a non-ordered reduction, what's the purpose of the new flag?
>>
>> This also needs a LangRef update.
>
> `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.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117480