<div dir="ltr">Are you llvm trunk or an older version?<div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">~Craig</div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 19, 2020 at 3:20 PM Hendrik Greving <<a href="mailto:hendrik.greving.smi@gmail.com">hendrik.greving.smi@gmail.com</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">Ok, interesting. The reason why this came up in the first place is that a 'vnot' pattern did not seem to match, neither does a (xor R:$m, (vNi1 (Splat 1))). But a (xor R:$m, (vNi1 (Splat -1))) does. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 19, 2020 at 3:11 PM Craig Topper <<a href="mailto:craig.topper@gmail.com" target="_blank">craig.topper@gmail.com</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">A constant i1 is stored as a one bit APInt wrapped in a ConstantInt which is then wrapped in ConstantSDNode for SelectionDAG. The BUILD_VECTOR will just point to the same ConstantSDNode for each element. There is no concept of a sign in the storage. It's just a bit. Whether or not its treated as 1 or negative 1 is going to depend on the code looking at the value including printing code. And nothing in the printing code knows about setBooleanVectorContents so it can't make any decisions about how to print it either. I believe SelectionDAGDumper just calls APInt::operator<<(raw_ostream &) which defaults to printing signed.<div><br clear="all"><div><div dir="ltr">~Craig</div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 19, 2020 at 3:01 PM Hendrik Greving <<a href="mailto:hendrik.greving.smi@gmail.com" target="_blank">hendrik.greving.smi@gmail.com</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">Yes the cited FIXME code might be unrelated. I do think there is _some_ kind of issue somewhere because I do see a BUILD_VECTOR of i1 -1 on our target which I set to setBooleanVectorContents(ZeroOrOneBooleanContent). The backend is not open source, but the i1 vector is an input to a clang builtin which takes V8i like<div>__builtin_special(~mask) where mask is an vector of i1 form a setne (cmp), and the vector of i1 -1 is from the ~ that does an xor of those two vectors. I would have expected a vector of 1, not -1. I would love to send in a better open source reproducer, will try to construct one.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 19, 2020 at 11:30 AM Craig Topper <<a href="mailto:craig.topper@gmail.com" target="_blank">craig.topper@gmail.com</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">The vnot PatFrag uses ImmAllOnesV which should put an OPC_CheckImmAllOnesV in the matcher table. And the matcher table should call ISD::isBuildVectorAllOnes. I believe we use vnot with vXi1 vectors on X86 and I haven't seen any issues.<div><br></div><div>The FIXME you pointed to seems related to a scalar patcher not a vector pattern. In that case the issue is that the immediate matcher for scalars calls getSExtValue on a 1-bit APInt which will return -1 in an int64_t.<br><div><br clear="all"><div><div dir="ltr">~Craig</div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 19, 2020 at 11:11 AM Tim Northover 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">Hi Hendrik,<br>
<br>
On Wed, 19 Feb 2020 at 11:01, Hendrik Greving via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> It looks like that in the DAG matcher, the DAG has a xor with '-1' for checking a true value vector<br>
><br>
> for instance,<br>
><br>
> %cmp4.i = icmp ne <8 x i32> %6, %5<br>
> %7 = xor <8 x i1> %cmp4.i, <i1 true, i1 true, i1 true, i1 true, i1 true, i1 true, i1 true, i1 true><br>
> [use of %7]<br>
><br>
> results in vector of  '-1' in the DAG.<br>
<br>
This should be controlled by TargetLowering::setBooleanVectorContents,<br>
which lets each target choose whether a boolean is 0/1 or 0/-1 when<br>
held in a larger register. For AMDGPU it looks like R600 wants 0/-1,<br>
but SIL wants 0/1 so if you're seeing -1 when compiling for a SIL<br>
target that's probably a bug.<br>
<br>
Cheers.<br>
<br>
Tim.<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>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>