[llvm-dev] how experimental are the llvm.experimental.vector.reduce.* functions?

[Craig Topper via llvm-dev]

I should mention the code I provided is equivalent to how the vector
version of sadd with overflow is expanded in the backend by default. Having
the vector intrinsic probably won’t improve the generated code over what
you can achieve with IR. Unless the target has some native way of detecting
overflow on vectors like the overflow flag on scalars.

On Sat, Feb 9, 2019 at 12:56 PM Andrew Kelley <andrew at ziglang.org> wrote:

> On 2/9/19 2:05 PM, Craig Topper wrote:
> > Something like this should work I think.
> >
> > ; ModuleID = 'test.ll'
> > source_filename = "test.ll"
> >
> > define void @entry(<4 x i32>* %a, <4 x i32>* %b, <4 x i32>* %x) {
> > Entry:
> >   %tmp = load <4 x i32>, <4 x i32>* %a, align 16
> >   %tmp1 = load <4 x i32>, <4 x i32>* %b, align 16
> >   %tmp2 = add <4 x i32> %tmp, %tmp1
> >   %tmpsign = icmp slt <4 x i32> %tmp, zeroinitializer
> >   %tmp1sign = icmp slt <4 x i32> %tmp1, zeroinitializer
> >   %sumsign = icmp slt <4 x i32> %tmp2, zeroinitializer
> >   %signsequal = icmp eq <4 x i1> %tmpsign, %tmp1sign
> >   %summismatch = icmp ne <4 x i1> %sumsign, %tmpsign
> >   %overflow = and <4 x i1> %signsequal, %summismatch
> >   %tmp5 = bitcast <4 x i1> %overflow to i4
> >   %tmp6 = icmp ne i4 %tmp5, 0
> >   br i1 %tmp6, label %OverflowFail, label %OverflowOk
> >
> > OverflowFail:                                     ; preds = %Entry
> >   tail call fastcc void @panic()
> >   unreachable
> >
> > OverflowOk:                                       ; preds = %Entry
> >   store <4 x i32> %tmp2, <4 x i32>* %x, align 16
> >   ret void
> > }
> >
> > declare fastcc void @panic()
>
>
> Thanks! I was able to get it working with your hint:
>
> >   %tmp5 = bitcast <4 x i1> %overflow to i4
>
> (Thanks also to LebedevRI who pointed this out on IRC)
>
> Until LLVM 9 when the llvm.*.with.overflow.* intrinsics gain vector
> support, here's what I ended up with:
>
>   %a = alloca <4 x i32>, align 16
>   %b = alloca <4 x i32>, align 16
>   %x = alloca <4 x i32>, align 16
>   store <4 x i32> <i32 1, i32 2, i32 3, i32 4>, <4 x i32>* %a, align 16,
> !dbg !55
>   store <4 x i32> <i32 5, i32 6, i32 7, i32 8>, <4 x i32>* %b, align 16,
> !dbg !56
>   %0 = load <4 x i32>, <4 x i32>* %a, align 16, !dbg !57
>   %1 = load <4 x i32>, <4 x i32>* %b, align 16, !dbg !58
>   %2 = sext <4 x i32> %0 to <4 x i33>, !dbg !59
>   %3 = sext <4 x i32> %1 to <4 x i33>, !dbg !59
>   %4 = add <4 x i33> %2, %3, !dbg !59
>   %5 = trunc <4 x i33> %4 to <4 x i32>, !dbg !59
>   %6 = sext <4 x i32> %5 to <4 x i33>, !dbg !59
>   %7 = icmp ne <4 x i33> %4, %6, !dbg !59
>   %8 = bitcast <4 x i1> %7 to i4, !dbg !59
>   %9 = icmp ne i4 %8, 0, !dbg !59
>   br i1 %9, label %OverflowFail, label %OverflowOk, !dbg !59
>
> Idea being: extend and do the operation with more bits. Truncate to get
> the result. Re-extend the result and check if it is the same as the
> pre-truncated result.
>
> This works pretty well unless the vector integer size is as big or
> larger than the native vector register. Here's a quick performance test:
>
> https://gist.github.com/andrewrk/b9734f9c310d8b79ec7271e7c0df4023
>
> Summary: safety-checked integer addition with no optimizations
>
> <4 x i32>:
> scalar = 893 MiB/s
> vector = 3.58 GiB/s
>
> <16 x i128>:
> scalar = 3.6 GiB/s
> vector = 2.5 GiB/s
>
>
> --
~Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190209/967b5fa7/attachment-0001.html>