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

[Hendrik Greving via llvm-dev]

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