[llvm-dev] i1 true ^= -1 in DAG matcher?

[Craig Topper via llvm-dev]

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 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/9a98cd88/attachment.html>