[llvm-dev] i1 true ^= -1 in DAG matcher? (original) (raw)

Hendrik Greving via llvm-dev llvm-dev at lists.llvm.org
Wed Feb 19 16🔞00 PST 2020

Pretty much trunk

On Wed, Feb 19, 2020 at 3:27 PM Craig Topper <craig.topper at gmail.com> wrote:

Are you llvm trunk or an older version?

~Craig

On Wed, Feb 19, 2020 at 3:20 PM Hendrik Greving <_ _hendrik.greving.smi at gmail.com> wrote: 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.

On Wed, Feb 19, 2020 at 3:11 PM Craig Topper <craig.topper at gmail.com> wrote:

A constant i1 is stored as a one bit APInt wrapped in a ConstantInt which is then wrapped in ConstantSDNode for SelectionDAG. The BUILDVECTOR 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<<(rawostream &) 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 BUILDVECTOR 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 _builtinspecial(~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 OPCCheckImmAllOnesV 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 int64t. ~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/25a3bde1/attachment.html>

More information about the llvm-dev mailing list