Hi,<br><br>So I think that the semantics of the absdiff intrinsic should be that there be no truncation of an intermediate result. That would, I think, match up with all the implementations I know of. <br><br>I am also happy to be corrected, it's now late my time :)<br><br>James<br><div class="gmail_quote"><div dir="ltr">On Mon, 3 Aug 2015 at 22:28, Mikhail Zolotukhin <<a href="mailto:mzolotukhin@apple.com">mzolotukhin@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi James,<div><br></div><div>According to LLVM Language reference manual, arithmetic operations do perform truncation:</div><div><span style="font-family:'Lucida Grande','Lucida Sans Unicode',Geneva,Verdana,sans-serif;font-size:14px;line-height:21px;background-color:rgb(255,255,255)">If the difference has unsigned overflow, the result returned is the mathematical result modulo 2</span><sup style="font-family:'Lucida Grande','Lucida Sans Unicode',Geneva,Verdana,sans-serif;line-height:21px">n</sup><span style="font-family:'Lucida Grande','Lucida Sans Unicode',Geneva,Verdana,sans-serif;font-size:14px;line-height:21px;background-color:rgb(255,255,255)">, where n is the bit width of the result.</span></div><div><br></div><div>So, I think that if we use "uge" for unsigned, we're actually fine here. But I'd be happy to be corrected if I'm wrong here:)</div><div><br></div><div>Michael</div></div><div style="word-wrap:break-word"><div><br><div><blockquote type="cite"><div>On Aug 3, 2015, at 1:09 PM, James Molloy <<a href="mailto:james@jamesmolloy.co.uk" target="_blank">james@jamesmolloy.co.uk</a>> wrote:</div><br><div>Hi Michael,<br><br>I think the complexity comes from the subtraction having as its domain two unsigned integers- so it's range must be a larger signed integer.<br><br>Signed comparison for unsigned values is clearly wrong as you say, but I could contruct a testcase that shows incorrect behaviour with an unsigned comparison too. I think the only correct behaviour is to extend the inputs first and truncate the result. <br><br>But I've been wrong before :)<br><br>James<br><div class="gmail_quote"><div dir="ltr">On Mon, 3 Aug 2015 at 21:05, Michael Zolotukhin <<a href="mailto:mzolotukhin@apple.com" target="_blank">mzolotukhin@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">mzolotukhin added inline comments.<br>
<br>
================<br>
Comment at: docs/LangRef.rst:10387-10390<br>
@@ -10386,6 +10386,6 @@<br>
<br>
%sub = sub nsw <4 x i32> %a, %b<br>
- %ispos = icmp sgt <4 x i32> %sub, <i32 -1, i32 -1, i32 -1, i32 -1><br>
+ %ispos = icmp sge <4 x i32> %sub, zeroinitializer<br>
%neg = sub nsw <4 x i32> zeroinitializer, %sub<br>
%1 = select <4 x i1> %ispos, <4 x i32> %sub, <4 x i32> %neg<br>
<br>
----------------<br>
ashahid wrote:<br>
> mzolotukhin wrote:<br>
> > What's the difference between `llvm.uabsdiff` and `llvm.sabsdiff` then?<br>
> The difference is the presence of NSW flag in case of llvm.sabsdiff.<br>
I still don't think it's correct. NSW is just a hint to optimizers, but it doesn't add any additional logic. It does assert that the expression won't overflow, but the operations we execute are still the same. That is, currently the only difference between signed and unsigned version is that for signed version we could get an undefined behavior in some cases. This is clearly incorrect, because we should get different results without undefined behavior in some cases (e.g. `<-1,-1,-1,-1>` and `<1,1,1,1>` - it should give `<254,254,254,254>` for `uabsdiff.v4i8` and `<2,2,2,2>` for `sabsdiff.v4i8`).<br>
<br>
What really should be the difference, as far is I understand, is condition code in the comparison:<br>
```<br>
%ispos = icmp sge <4 x i32> %sub, zeroinitializer<br>
```<br>
As far as I understand, we should use `uge` for unsigned and `sge` for signed case.<br>
<br>
<br>
<br>
Repository:<br>
rL LLVM<br>
<br>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D11678&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=4JFyLraejVeSc8ivugxm9QaGbaLfo9cfDMJdozR61Nk&s=He8HN-ctArHj6hmEV30D-XDYblh-bEm9uYybmVT5Cwk&e=" rel="noreferrer" target="_blank">http://reviews.llvm.org/D11678</a><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</blockquote></div>
</div></blockquote></div><br></div></div></blockquote></div>