handling OpCopyLogical

[bashbaug]

Possibly related to #2460 and #2484.

I've been adding SPIR-V 1.4 CTS testing and testing for OpCopyLogical specifically and I'd like to confirm how this instruction is supposed to behave. If helpful, my WIP tests are here:

KhronosGroup/OpenCL-CTS@main...bashbaug:OpenCL-CTS:spirv-14-part5

The SPIR-V file I am using for this test is:

; SPIR-V
; Version: 1.4
               OpCapability Addresses
               OpCapability Kernel
               OpMemoryModel Physical64 OpenCL
               OpEntryPoint Kernel %kernel "copylogical_test"
       %uint = OpTypeInt 32 0
      %float = OpTypeFloat 32
       %void = OpTypeVoid
   %struct_a = OpTypeStruct %uint %float
%ptr_struct_a = OpTypePointer CrossWorkgroup %struct_a
   %struct_b = OpTypeStruct %uint %float
%ptr_struct_b = OpTypePointer CrossWorkgroup %struct_b
 %kernel_sig = OpTypeFunction %void %ptr_struct_b
  %uint_1024 = OpConstant %uint 1024
   %float_pi = OpConstant %float 3.1415
%struct_a_src = OpConstantComposite %struct_a %uint_1024 %float_pi
     %kernel = OpFunction %void None %kernel_sig
        %dst = OpFunctionParameter %ptr_struct_b
      %entry = OpLabel
%struct_b_dst = OpCopyLogical %struct_b %struct_a_src
               OpStore %dst %struct_b_dst
               OpReturn
               OpFunctionEnd

It essentially copies a structure with an integer and a float, then stores it to memory. This was inspired by a similar existing test that uses OpCopyObject instead of OpCopyLogical.

After SPIR-V to LLVM translation, this case generates:

; ModuleID = '/home/bashbaug/git/OpenCL-CTS/test_conformance/spirv_new/spirv_bin/spv1.4/copylogical_struct.bc'
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v16:16:16-v24:32:32-v32:32:32-v48:64:64-v64:64:64-v96:128:128-v128:128:128-v192:256:256-v256:256:256-v512:512:512-v1024:1024:1024-G1"
target triple = "spir64-unknown-unknown"

%structtype.0 = type { i32, float }
%structtype = type { i32, float }

; Function Attrs: nounwind
define spir_kernel void @copylogical_test(ptr addrspace(1) %0) #0 !kernel_arg_addr_space !5 !kernel_arg_access_qual !6 !kernel_arg_type !7 !kernel_arg_type_qual !8 !kernel_arg_base_type !7 !spirv.ParameterDecorations !9 {
  call spir_func void @_Z19__spirv_CopyLogical12structtype.0(ptr addrspace(1) sret(%structtype) %0, %structtype.0 { i32 1024, float 0x400921CAC0000000 })
  ret void
}

declare spir_func void @_Z19__spirv_CopyLogical12structtype.0(ptr addrspace(1) sret(%structtype), %structtype.0)

Is this the expected behavior? Should SPIR-V consumers need to provide an implementation of __spirv_CopyLogical? Or, could/should we translate this to something like llvm.memcpy instead?

For reference, a similar test using OpCopyObject instead of OpCopyLogical generates:

; ModuleID = '/home/bashbaug/git/OpenCL-CTS/test_conformance/spirv_new/spirv_bin/spv1.4/copyobject_struct.bc'
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v16:16:16-v24:32:32-v32:32:32-v48:64:64-v64:64:64-v96:128:128-v128:128:128-v192:256:256-v256:256:256-v512:512:512-v1024:1024:1024"
target triple = "spir64-unknown-unknown"

%structtype = type { i32, float }

; Function Attrs: nounwind
define spir_kernel void @copylogical_test(ptr addrspace(1) %0) #0 !kernel_arg_addr_space !5 !kernel_arg_access_qual !6 !kernel_arg_type !7 !kernel_arg_type_qual !8 !kernel_arg_base_type !7 !spirv.ParameterDecorations !9 {
  %2 = alloca %structtype, align 8
  store %structtype { i32 1024, float 0x400921CAC0000000 }, ptr %2, align 4
  %3 = load %structtype, ptr %2, align 4
  store %structtype %3, ptr addrspace(1) %0, align 4
  ret void
}

[svenvh]

Presumably the SPIR-V reader should be able to lower OpCopyLogical to llvm.memcpy; it might mean that we cannot easily retain OpCopyLogical on a SPIR-V -> LLVM -> SPIR-V round trip but that shouldn't be a major issue.

@vmaksimo you did the implementation in #2484 , any thoughts from your side?