llvm dev - Apr 2020 - RFC: Promoting experimental reduction intrinsics to first class intrinsics

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.

Cheers,
Amara

Hi Amara,

Can you provide a pointer to the docs that describe these?

-Chris
> On Apr 7, 2020, at 9:59 PM, 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.
> 
> Cheers,
> Amara
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Sure, they’re documented in the langref:
http://llvm.org/docs/LangRef.html#experimental-vector-reduction-intrinsics
<http://llvm.org/docs/LangRef.html#experimental-vector-reduction-intrinsics>

Amara
> On Apr 8, 2020, at 9:24 AM, Chris Lattner <clattner at nondot.org>
wrote:
> 
> Hi Amara,
> 
> Can you provide a pointer to the docs that describe these?
> 
> -Chris
> 
>> On Apr 7, 2020, at 9:59 PM, 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.
>> 
>> Cheers,
>> Amara
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200408/8d57e062/attachment.html>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200408/2d4744fd/attachment.html>

> On Apr 8, 2020, at 9:54 AM, Nikita Popov <nikita.ppv at gmail.com>
wrote:
> 
> On Wed, Apr 8, 2020 at 6:59 AM Amara Emerson via llvm-dev <llvm-dev at
lists.llvm.org <mailto: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.
I think without the nnan flag, the semantics should be equivalent to an ordered
(i.e. serialized) reduction of llvm.fmin/fmaxnum. Any issues with
this?
> 
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200408/3955ee72/attachment.html>

My experience with them so far is that the code generation for these 
intrinsics is still missing a lot of cases.  Some of them are X86 
specific (the target I look at mostly), but many of them have generic forms.

As one recent example, consider 
https://bugs.llvm.org/show_bug.cgi?id=45378.  (There's nothing special 
about this one other than it was recent.)

I'm not necessarily arguing they can't be promoted from experimental, 
but it would be a much easier case if the code gen was routinely as good 
or better than the scalar forms.  Or to say that a bit differently, if 
we could canonicalize to them in the IR without major regression.  
Having two ways to represent something in the IR without any agreed upon 
canonical form is always sub-optimal.

Philip

On 4/7/20 9:59 PM, Amara Emerson via llvm-dev 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.
>
> Cheers,
> Amara
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

That recent X86 bug isn't unique to the intrinsic. We generate the same
code from this which uses the shuffle sequence the vectorizers generated
before the reduction intrinsics existed.

declare i64 @llvm.experimental.vector.reduce.or.v2i64(<2 x i64>)·
declare void @TrapFunc(i64)

define void @parseHeaders(i64 * %ptr) {
  %vptr = bitcast i64 * %ptr to <2 x i64> *
  %vload = load <2 x i64>, <2 x i64> * %vptr, align 8

  %b = shufflevector <2 x i64> %vload, <2 x i64> undef, <2 x
i32> <i32 1,
i32 undef>
  %c = or <2 x i64> %vload, %b
  %vreduce = extractelement <2 x i64> %c, i32 0

  %vcheck = icmp eq i64 %vreduce, 0
  br i1 %vcheck, label %ret, label %trap
trap:
  %v2 = extractelement <2 x i64> %vload, i32 1
  call void @TrapFunc(i64 %v2)
  ret void
ret:
  ret void
}

~Craig


On Thu, Apr 9, 2020 at 10:04 AM Philip Reames via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> My experience with them so far is that the code generation for these
> intrinsics is still missing a lot of cases.  Some of them are X86
> specific (the target I look at mostly), but many of them have generic
> forms.
>
> As one recent example, consider
> https://bugs.llvm.org/show_bug.cgi?id=45378.  (There's nothing special
> about this one other than it was recent.)
>
> I'm not necessarily arguing they can't be promoted from
experimental,
> but it would be a much easier case if the code gen was routinely as good
> or better than the scalar forms.  Or to say that a bit differently, if
> we could canonicalize to them in the IR without major regression.
> Having two ways to represent something in the IR without any agreed upon
> canonical form is always sub-optimal.
>
> Philip
>
> On 4/7/20 9:59 PM, Amara Emerson via llvm-dev 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.
> >
> > Cheers,
> > Amara
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200409/9234f31c/attachment.html>

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