Per OPenCL 1.2 spec 6.1.5: For 3-component vector data types, the size of the data type is 4 * sizeof(component). The spec does not explicitly say what the padding componenet will be, it should be implementation-dependent, so, let's fill zero for the padding componenet instead of just caring the 3 components, and the sends instruction will be decreased (from 4 sends to 1 sends for short3* case).
Signed-off-by: Guo Yejun <[email protected]> --- backend/src/llvm/llvm_gen_backend.cpp | 7 ------- 1 file changed, 7 deletions(-) diff --git a/backend/src/llvm/llvm_gen_backend.cpp b/backend/src/llvm/llvm_gen_backend.cpp index 4122bdb..5135950 100644 --- a/backend/src/llvm/llvm_gen_backend.cpp +++ b/backend/src/llvm/llvm_gen_backend.cpp @@ -5180,13 +5180,6 @@ namespace gbe uint32_t elemNum = vectorType->getNumElements(); GBE_ASSERTM(elemNum == 2 || elemNum == 3 || elemNum == 4 || elemNum == 8 || elemNum == 16, "Only vectors of 2,3,4,8 or 16 elements are supported"); - // Per OPenCL 1.2 spec 6.1.5: - // For 3-component vector data types, the size of the data type is 4 * sizeof(component). - // And the llvm does cast a type3 data to type4 for load/store instruction, - // so a 4 elements vector may only have 3 valid elements. We need to fix it to correct element - // count here. - if (elemNum == 4 && writer->regTranslator.isUndefConst(llvmValues, 3)) - elemNum = 3; // The code is going to be fairly different from types to types (based on // size of each vector element) -- 1.9.1 _______________________________________________ Beignet mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/beignet
