Displaying 6 results from an estimated 6 matches for "vnot".
Did you mean:
not
2020 Feb 19
2
i1 true ^= -1 in DAG matcher?
...~ 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 t...
2020 Feb 19
2
i1 true ^= -1 in DAG matcher?
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 ve...
2020 Feb 19
2
i1 true ^= -1 in DAG matcher?
...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 seem...
2009 May 15
1
[LLVMdev] RFC: More AVX Experience
...d (not (INTTYPE (bitconvert (TYPE SRCREGCLASS:$src1)))),
(INTTYPE (MEMOP ADDRCLASS:$src2)))))]]>;
// Vector
defm ANDN : sse1_sse2_avx_binary_vector_tb_ostb_node_pattern_rm_rrm<
0x55,
"andn",
[[(set DSTREGCLASS:$dst,
(INTTYPE (and (vnot (INTTYPE (bitconvert (TYPE SRCREGCLASS:$src1)))),
(INTTYPE (MEMOP ADDRCLASS:$src2)))))]]>;
The "not" vs. "vnot" is unfortunate. I could add another class argument that
says "instantiate with members of this list of operators" but see below about...
2009 Apr 30
6
[LLVMdev] RFC: AVX Pattern Specification [LONG]
...VR128:$src2)))]>;
SSE2 :
def ANDNPDrr : PDI<0x55, MRMSrcReg,
(outs VR128:$dst), (ins VR128:$src1, VR128:$src2),
"andnpd\t{$src2, $dst|$dst, $src2}",
[(set VR128:$dst,
(and (vnot (bc_v2i64 (v2f64 VR128:$src1))),
(bc_v2i64 (v2f64 VR128:$src2))))]>;
Note the use of xor vs. vnot and the different placement of the bc* fragments
and use of type specifiers. I wonder if we even match both of these.
And naming is not consistent:
def Int_CVTSS2SIrr : S...
2009 May 01
0
[LLVMdev] RFC: AVX Pattern Specification [LONG]
...retrofitted in later to avoid some of the duplicated code. Where they
are used, they aren't used as well as they could be.
> Moreover, the various SSE levels were implemented at different times
> and do
> things subtly differently. For example:
>
> Note the use of xor vs. vnot and the different placement of the bc*
> fragments
> and use of type specifiers. I wonder if we even match both of these.
Right, we have the same problem within the GPR operations. Ideally
we'd have a multiclass for most arithmetic operations that expands out
into 8/16/32/64-bit...