Hendrik Greving via llvm-dev
2020-Feb-19 19:01 UTC
[llvm-dev] i1 true ^= -1 in DAG matcher?
Hello, 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 also seems the reason why LLVM's vnot PatFrag doesn't match in this case. I've also found f rom third_party/llvm/llvm-project/llvm/lib/Target/AMDGPU/SIInstructions.td: // FIXME: The generated DAG matcher seems to have strange behavior // with a 1-bit literal to match, so use a -1 for checking a true // 1-bit value. Which seems to reflect the same observation. Is this a bug or a feature? Thanks in advance for any explanation -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200219/3c2aeca5/attachment.html>
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.
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>