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. 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. ~Craig On Wed, Feb 19, 2020 at 11:11 AM Tim Northover via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi Hendrik, > > On Wed, 19 Feb 2020 at 11:01, Hendrik Greving via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > It looks like that in the DAG matcher, the DAG has a xor with '-1' for > checking a true value vector > > > > for instance, > > > > %cmp4.i = icmp ne <8 x i32> %6, %5 > > %7 = xor <8 x i1> %cmp4.i, <i1 true, i1 true, i1 true, i1 true, i1 true, > i1 true, i1 true, i1 true> > > [use of %7] > > > > results in vector of '-1' in the DAG. > > This should be controlled by TargetLowering::setBooleanVectorContents, > which lets each target choose whether a boolean is 0/1 or 0/-1 when > held in a larger register. For AMDGPU it looks like R600 wants 0/-1, > but SIL wants 0/1 so if you're seeing -1 when compiling for a SIL > target that's probably a bug. > > Cheers. > > Tim. > _______________________________________________ > 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/20200219/5e3da1c0/attachment.html>
Hendrik Greving via llvm-dev
2020-Feb-19 23:00 UTC
[llvm-dev] i1 true ^= -1 in DAG matcher?
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 __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. On Wed, Feb 19, 2020 at 11:30 AM Craig Topper <craig.topper at gmail.com> wrote:> 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. > > 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. > > ~Craig > > > On Wed, Feb 19, 2020 at 11:11 AM Tim Northover via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi Hendrik, >> >> On Wed, 19 Feb 2020 at 11:01, Hendrik Greving via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> > It looks like that in the DAG matcher, the DAG has a xor with '-1' for >> checking a true value vector >> > >> > for instance, >> > >> > %cmp4.i = icmp ne <8 x i32> %6, %5 >> > %7 = xor <8 x i1> %cmp4.i, <i1 true, i1 true, i1 true, i1 true, i1 >> true, i1 true, i1 true, i1 true> >> > [use of %7] >> > >> > results in vector of '-1' in the DAG. >> >> This should be controlled by TargetLowering::setBooleanVectorContents, >> which lets each target choose whether a boolean is 0/1 or 0/-1 when >> held in a larger register. For AMDGPU it looks like R600 wants 0/-1, >> but SIL wants 0/1 so if you're seeing -1 when compiling for a SIL >> target that's probably a bug. >> >> Cheers. >> >> Tim. >> _______________________________________________ >> 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/20200219/5bdf6e9f/attachment.html>
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. ~Craig On Wed, Feb 19, 2020 at 3:01 PM Hendrik Greving < hendrik.greving.smi at gmail.com> wrote:> 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 > __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. > > On Wed, Feb 19, 2020 at 11:30 AM Craig Topper <craig.topper at gmail.com> > wrote: > >> 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. >> >> 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. >> >> ~Craig >> >> >> On Wed, Feb 19, 2020 at 11:11 AM Tim Northover via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Hi Hendrik, >>> >>> On Wed, 19 Feb 2020 at 11:01, Hendrik Greving via llvm-dev >>> <llvm-dev at lists.llvm.org> wrote: >>> > It looks like that in the DAG matcher, the DAG has a xor with '-1' for >>> checking a true value vector >>> > >>> > for instance, >>> > >>> > %cmp4.i = icmp ne <8 x i32> %6, %5 >>> > %7 = xor <8 x i1> %cmp4.i, <i1 true, i1 true, i1 true, i1 true, i1 >>> true, i1 true, i1 true, i1 true> >>> > [use of %7] >>> > >>> > results in vector of '-1' in the DAG. >>> >>> This should be controlled by TargetLowering::setBooleanVectorContents, >>> which lets each target choose whether a boolean is 0/1 or 0/-1 when >>> held in a larger register. For AMDGPU it looks like R600 wants 0/-1, >>> but SIL wants 0/1 so if you're seeing -1 when compiling for a SIL >>> target that's probably a bug. >>> >>> Cheers. >>> >>> Tim. >>> _______________________________________________ >>> 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/20200219/e944b84d/attachment.html>