<div dir="ltr"><div dir="ltr"><div>The IR update to allow vector types was here:</div><div><a href="https://reviews.llvm.org/D57090" target="_blank">https://reviews.llvm.org/D57090</a></div><div>...we didn't update the docs at that time because it was not clear what the backend would do with that, but that might've changed with some of the more recent patches.<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 9, 2019 at 1:42 AM Craig Topper via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I don't think I understand your pseudocode using llvm.experimental.vector.reduce.umax. All of the types you showed are scalar, but that intrinsic doesn't work on scalars so I'm having a hard time understanding what you're trying to do with it. llvm.experimental.vector.reduce.umax takes a vector input and returns a scalar result. Are you wanting to find if any of the additions overflowed or a mask of which addition overflowed?</div><div><br></div><div>The sadd.with.overflow intrinsics are in the process of gaining vector support if not already complete. Simon Pilgrim made some commits recently. I know the documentation in the LangRef hasn't been updated. It will return a <X x i1> vector for overflow instead i1 when vectors are used.<br clear="all"><div><div dir="ltr" class="gmail-m_4449654481036451476gmail-m_5382894755028859465gmail_signature"><br></div><div dir="ltr" class="gmail-m_4449654481036451476gmail-m_5382894755028859465gmail_signature">~Craig</div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 8, 2019 at 11:03 PM Andrew Kelley via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I'm interested in using @llvm.experimental.vector.reduce.smax/umax to<br>
implement runtime overflow checking for vectors. Here's an example<br>
checked addition, without vectors, and then I'll follow the example with<br>
what I would do for checked addition with vectors.<br>
<br>
Frontend code (zig):<br>
<br>
export fn entry() void {<br>
var a: i32 = 1;<br>
var b: i32 = 2;<br>
var x = a + b;<br>
}<br>
<br>
LLVM IR code:<br>
<br>
define void @entry() #2 !dbg !41 {<br>
Entry:<br>
%a = alloca i32, align 4<br>
%b = alloca i32, align 4<br>
%x = alloca i32, align 4<br>
store i32 1, i32* %a, align 4, !dbg !52<br>
call void @llvm.dbg.declare(metadata i32* %a, metadata !45, metadata<br>
!DIExpression()), !dbg !52<br>
store i32 2, i32* %b, align 4, !dbg !53<br>
call void @llvm.dbg.declare(metadata i32* %b, metadata !48, metadata<br>
!DIExpression()), !dbg !53<br>
%0 = load i32, i32* %a, align 4, !dbg !54<br>
%1 = load i32, i32* %b, align 4, !dbg !55<br>
%2 = call { i32, i1 } @llvm.sadd.with.overflow.i32(i32 %0, i32 %1),<br>
!dbg !56<br>
%3 = extractvalue { i32, i1 } %2, 0, !dbg !56<br>
%4 = extractvalue { i32, i1 } %2, 1, !dbg !56<br>
br i1 %4, label %OverflowFail, label %OverflowOk, !dbg !56<br>
<br>
OverflowFail: ; preds = %Entry<br>
tail call fastcc void @panic(%"[]u8"* @2, %StackTrace* null), !dbg !56<br>
unreachable, !dbg !56<br>
<br>
OverflowOk: ; preds = %Entry<br>
store i32 %3, i32* %x, align 4, !dbg !57<br>
call void @llvm.dbg.declare(metadata i32* %x, metadata !50, metadata<br>
!DIExpression()), !dbg !57<br>
ret void, !dbg !58<br>
}<br>
<br>
You can see this takes advantage of @llvm.sadd.with.overflow, which is<br>
not available with vectors. So here is a different approach (pseudocode):<br>
<br>
%a_zext = zext %a to i33 # 1 more bit<br>
%b_zext = zext %b to i33 # 1 more bit<br>
%result_zext = add %a_zext, %b_zext<br>
%max_result = @llvm.experimental.vector.reduce.umax(%result_zext)<br>
%overflow = icmp %max_result > @max_i32_value<br>
%result = trunc %result_zext to i32<br>
<br>
You can imagine how this would work for signed integers, replacing zext<br>
with sext and umax with smax.<br>
<br>
This depends on an "experimental" API. Can anyone advise on depending on<br>
this API? Is it a bad idea? Is it about to be promoted to<br>
non-experimental soon? Can anyone advise on how to best achieve my goal?<br>
<br>
Kind regards,<br>
Andrew<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>