search for: spir_kernel

...f OpenCL builtins are mangled. However, when I compile OpenCl code with Clang 3.9 with the "spir64-unknown-unknown" target, Clang generates IR without mangling the builtins, e.g. for: __kernel void input_zip_int(__global int *in0) { *in0 = get_global_id(0); } clang generates: define spir_kernel void @input_zip_int(i32 addrspace(1)* nocapture %in0) local_unnamed_addr #0 !kernel_arg_addr_space !3 !kernel_arg_access_qual !4 !kernel_arg_type !5 !kernel_arg_base_type !5 !kernel_arg_type_qual !6 { entry: %call = tail call spir_func i128 @get_global_id(i32 0) #2 %conv = trunc i128 %call to i...

Hello everyone, I think I have found an gvn / alias analysis related bug, but before opening an issue on the tracker I wanted to see if I am missing something. I have the following testcase: define spir_kernel void @test(<2 x i32*> %in1, <2 x i32*> %in2, i32* %out) { > entry: > ; Just some temporary storage > %tmp.0 = alloca i32 > %tmp.1 = alloca i32 > %tmp.i = insertelement <2 x i32*> undef, i32* %tmp.0, i32 0 > %tmp = insertelement <2 x i32*> %tmp.i,...

...ts.llvm.org> wrote: > > Hello everyone, > > > > I think I have found an gvn / alias analysis related bug, but before > opening > > an issue on the tracker I wanted to see if I am missing something. I have > > the following testcase: > > > >> define spir_kernel void @test(<2 x i32*> %in1, <2 x i32*> %in2, i32* > %out) > >> { > >> entry: > >> ; Just some temporary storage > >> %tmp.0 = alloca i32 > >> %tmp.1 = alloca i32 > >> %tmp.i = insertelement <2 x i32*> undef, i32* %tm...

...the > "spir64-unknown-unknown" target, Clang generates IR without mangling the > builtins, e.g. for: > > > > __kernel void input_zip_int(__global int *in0) { > > *in0 = get_global_id(0); > > } > > > > clang generates: > > > > define spir_kernel void @input_zip_int(i32 addrspace(1)* nocapture %in0) > local_unnamed_addr #0 !kernel_arg_addr_space !3 !kernel_arg_access_qual !4 > !kernel_arg_type !5 !kernel_arg_base_type !5 !kernel_arg_type_qual !6 { > > entry: > > %call = tail call spir_func i128 @get_global_id(i32 0) #2 &...

...t;>> > I think I have found an gvn / alias analysis related bug, but before >>> opening >>> > an issue on the tracker I wanted to see if I am missing something. I >>> have >>> > the following testcase: >>> > >>> >> define spir_kernel void @test(<2 x i32*> %in1, <2 x i32*> %in2, i32* >>> %out) >>> >> { >>> >> entry: >>> >> ; Just some temporary storage >>> >> %tmp.0 = alloca i32 >>> >> %tmp.1 = alloca i32 >>> >>...

...I have found an gvn / alias analysis related bug, but before >>>> opening >>>> > an issue on the tracker I wanted to see if I am missing something. I >>>> have >>>> > the following testcase: >>>> > >>>> >> define spir_kernel void @test(<2 x i32*> %in1, <2 x i32*> %in2, i32* >>>> %out) >>>> >> { >>>> >> entry: >>>> >> ; Just some temporary storage >>>> >> %tmp.0 = alloca i32 >>>> >> %tmp.1 = alloca i32...

...; > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> define spir_kernel void @test(<2 x i32*> %in1, <2 x > > > > > > > >> i32*> > > > > > > > >> %in2, > > > > > > > >> i32* %out) > > > > > > > > > > > > > > > > > > >...

...f OpenCL builtins are mangled. However, when I compile OpenCl code with Clang 3.9 with the "spir64-unknown-unknown" target, Clang generates IR without mangling the builtins, e.g. for: __kernel void input_zip_int(__global int *in0) { *in0 = get_global_id(0); } clang generates: define spir_kernel void @input_zip_int(i32 addrspace(1)* nocapture %in0) local_unnamed_addr #0 !kernel_arg_addr_space !3 !kernel_arg_access_qual !4 !kernel_arg_type !5 !kernel_arg_base_type !5 !kernel_arg_type_qual !6 { entry: %call = tail call spir_func i128 @get_global_id(i32 0) #2 %conv = trunc i128 %call to i...

...t;>> before opening >>>>>>> > an issue on the tracker I wanted to see if I am missing something. >>>>>>> I have >>>>>>> > the following testcase: >>>>>>> > >>>>>>> >> define spir_kernel void @test(<2 x i32*> %in1, <2 x i32*> %in2, >>>>>>> i32* %out) >>>>>>> >> { >>>>>>> >> entry: >>>>>>> >> ; Just some temporary storage >>>>>>> >> %tmp.0...

...ening >>>>>>>> > an issue on the tracker I wanted to see if I am missing >>>>>>>> something. I have >>>>>>>> > the following testcase: >>>>>>>> > >>>>>>>> >> define spir_kernel void @test(<2 x i32*> %in1, <2 x i32*> %in2, >>>>>>>> i32* %out) >>>>>>>> >> { >>>>>>>> >> entry: >>>>>>>> >> ; Just some temporary storage >>>>>>>&gt...

...f OpenCL builtins are mangled. However, when I compile OpenCl code with Clang 3.9 with the "spir64-unknown-unknown" target, Clang generates IR without mangling the builtins, e.g. for: __kernel void input_zip_int(__global int *in0) { *in0 = get_global_id(0); } clang generates: define spir_kernel void @input_zip_int(i32 addrspace(1)* nocapture %in0) local_unnamed_addr #0 !kernel_arg_addr_space !3 !kernel_arg_access_qual !4 !kernel_arg_type !5 !kernel_arg_base_type !5 !kernel_arg_type_qual !6 { entry: %call = tail call spir_func i128 @get_global_id(i32 0) #2 %conv = trunc i128 %call to i...

...onventions The following calling conventions are valid tokens but not described in the language references as of revision 223189: intel_ocl_bicc, x86_stdcallcc, x86_fastcallcc, x86_thiscallcc, kw_x86_vectorcallcc, arm_apcscc, arm_aapcscc, arm_aapcs_vfpcc, msp430_intrcc, ptx_kernel, ptx_device, spir_kernel, spir_func, x86_64_sysvcc, x86_64_win64cc, kw_ghccc Lastly I'd just like to thank the LLVM developers for all the time and hard work they've put into this project. I'd especially like to thank you for providing a language specification along side of the reference implementation!...

...s but not described in >>> the language references as of revision 223189: >>> >>> intel_ocl_bicc, x86_stdcallcc, x86_fastcallcc, x86_thiscallcc, >>> kw_x86_vectorcallcc, arm_apcscc, arm_aapcscc, arm_aapcs_vfpcc, >>> msp430_intrcc, ptx_kernel, ptx_device, spir_kernel, spir_func, >>> x86_64_sysvcc, x86_64_win64cc, kw_ghccc >>> >>> >>> This is just bitrot. >> >> -- Sean Silva >> >> >> >>> >>> Lastly I'd just like to thank the LLVM developers for all the time and >>>...

...ions are valid tokens but not described in >> the language references as of revision 223189: >> >> intel_ocl_bicc, x86_stdcallcc, x86_fastcallcc, x86_thiscallcc, >> kw_x86_vectorcallcc, arm_apcscc, arm_aapcscc, arm_aapcs_vfpcc, >> msp430_intrcc, ptx_kernel, ptx_device, spir_kernel, spir_func, >> x86_64_sysvcc, x86_64_win64cc, kw_ghccc >> >> > This is just bitrot. > > -- Sean Silva > > >> >> >> Lastly I'd just like to thank the LLVM developers for all the time and >> hard work they've put into this project. I...

...f revision 223189: >>>>>>> >>>>>>> intel_ocl_bicc, x86_stdcallcc, x86_fastcallcc, x86_thiscallcc, >>>>>>> kw_x86_vectorcallcc, arm_apcscc, arm_aapcscc, arm_aapcs_vfpcc, >>>>>>> msp430_intrcc, ptx_kernel, ptx_device, spir_kernel, spir_func, >>>>>>> x86_64_sysvcc, x86_64_win64cc, kw_ghccc >>>>>>> >>>>>>> >>>>>>> This is just bitrot. >>>>>>> >>>>>>> >>>>>> -- Sean Silva >>&g...