[llvm-dev] RFC: Promoting experimental reduction intrinsics to first class intrinsics

[Simon Moll via llvm-dev]

Hi,

Yes, we absolutely would want masked reductions. Those are already
planned for VP intrinsics https://reviews.llvm.org/D57504

I'd very much appreciate if we could cooperate on this and implement
masked reduction intrinsics in the llvm.vp.* namespace following the
schema of the VP intrinsics that are already upstream
(https://llvm.org/docs/LangRef.html#vector-predication-intrinsics).

Btw, i am working on the VP to non-VP expansion pass. If
`llvm.vp.reduce.*` intrinsics should replace the existing ones then
that's the pass where their expansion would be implemented as well.

Cheers
- Simon


On 4/15/20 2:30 PM, David Green via llvm-dev wrote:
> Hello
>
> We (ARM / MVE) would also at some point want to add the concept of masked reductions. This could either be done by extending the existing intrinsics much like how a masked gather/scatter works, or with an entirely new set of intrinsics. I'm not sure which way is better in the long run, but the masked variants probably have a superset of the functionality of the non-masked ones, considering the mask can be all ones.
>
> I believe other vector architectures such as SVE and the VE target might make use of these too, but perhaps with slightly different semantics around active vector lengths.
> Dave
>
>
>
>
>
>
>
> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Nikita Popov via llvm-dev <llvm-dev at lists.llvm.org>
>
> Sent: 08 April 2020 17:54
>
> To: Amara Emerson <aemerson at apple.com>
>
> Cc: LLVM Developers' List <llvm-dev at lists.llvm.org>
>
> Subject: Re: [llvm-dev] RFC: Promoting experimental reduction intrinsics to first class intrinsics
>
>  
>
>
>
>
> On Wed, Apr 8, 2020 at 6:59 AM Amara Emerson via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
>
>
> Hi,
>
>
>
> It’s been a few years now since I added some intrinsics for doing vector reductions. We’ve been using them exclusively on AArch64, and I’ve seen some traffic a while ago on list for other targets too. Sander did some work last year to refine the semantics after
>  some discussion.
>
>
>
> Are we at the point where we can drop the “experimental” from the name? IMO all target should begin to transition to using these as the preferred representation for reductions. But for now, I’m only proposing the naming change.
>
>
>
>
>
> There's still a couple of open issues that I'm aware of:
>
>
>
> 1. fmin/fmax reductions without nnan flag do not work. IR expansion code assumes that these always use FMF. It's also under-documented what their exact behavior is, though I assume it should match llvm.minnum/llvm.maxnum semantics to be most useful.
>
>
>
> 2. SDAG legalization support for float softening is missing.
>
>
>
>
>
> 3. SDAG legalization for ordered reductions is missing.
>
>
>
> I think point 1 is the only real blocker here, the rest can be avoided by force-expanding these cases in IR.
>
>
>
> Regards,
>
>
> Nikita
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>