[PATCH] D13633: Type legalizer for masked gather/scatter intrinsics

Mitch Bodart via llvm-commits llvm-commits at lists.llvm.org
Fri Nov 6 16:04:14 PST 2015


mbodart added inline comments.

================
Comment at: ../include/llvm/CodeGen/SelectionDAGNodes.h:2117-2119
@@ -2118,2 +2116,5 @@
            "Vector width mismatch between mask and data");
+    assert(getIndex().getValueType().getVectorNumElements() ==
+           getValueType(0).getVectorNumElements() &&
+           "Vector width mismatch between index and data");
   }
----------------
delena wrote:
> Mask types are not always legal. When <2xi1> is illegal, the type legalizer promotes it to <2 x i64>.
> I create the node with <2 x i64> mask and then handle it in X86 code.
Allowing non-i1 element types, even temporarily, seems like it breaks the definition of MGATHER/MSCATTER.  Do we need to update the LLVM documentation to allow simd masks here?  Or is it the intent to require i1 masks throughout LLVM IR, and only allow simd masks while we perform type legalization during during DAG selection?  If the latter, that still seems a bit risky as type legalization can use utilities in the non-target-specific parts of CodeGen, and they would not like to see a non-i1 mask element.  That's just paranoid speculation on my part.  I don't know whether DAG selection is in general allowed to take such liberties.

A related question:  Why isn't <2xi1> legalized to a full mask register size (<64xi1>, <32xi1>, <16xi1> or <8xi1>) instead of <2xi64>?
Is this just inherent in type legalization of Nxi1 vectors, or is it needed for an AVX2 simd mask?

================
Comment at: ../test/CodeGen/X86/masked_gather_scatter.ll:170
@@ +169,3 @@
+; SKX-NEXT:    kmovw %k1, %k2
+; SKX-NEXT:    vpgatherdd (%rdi,%ymm0,4), %ymm1 {%k2}
+; SKX-NEXT:    vmovaps %zmm1, %zmm2
----------------
delena wrote:
> The base address in %rdi. (In %edi for 32-bit). In %ymm0 we have only indices. The real address of each element is  "base +index*scale" ->  %rdi + ymm[i] * 4
OK, thanks.


Repository:
  rL LLVM

http://reviews.llvm.org/D13633





More information about the llvm-commits mailing list