llvm dev - Feb 2020 - 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>