[cfe-dev] OpenCL Address Spaces and Runtimes
Speziale Ettore
speziale.ettore at gmail.com
Thu Apr 14 06:44:48 PDT 2011
Hi,
> I asked about whether OpenCL backends would possibly need this
> information and was informed that they wouldn't. If that's not true, then
> we should move to a different representation, like a normal decl
> attribute instead of a type attribute.
I think the most important thing should be consistency. Since it has
been chosen to exploit metadata to keep kernel information inside llvm
bitcode, a similar approach must be used to keep information about
address spaces.
Path attached, with minor edits with respect to the proposed approach.
Comments are welcome.
Best regards,
speziale.ettore at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: address-spaces-metadata.patch
Type: text/x-patch
Size: 3959 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110414/b4343383/attachment.bin>
-------------- next part --------------
kernel void NDRangeHello(global char *a, local char *b, int c) { }
kernel void NDRangeNull() { }
-------------- next part --------------
; ModuleID = 'test.cl'
target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32"
target triple = "i386-pc-linux-gnu"
define void @NDRangeHello(i8 addrspace(1)* nocapture %a, i8 addrspace(2)* nocapture %b, i32 %c) nounwind readnone {
entry:
ret void
}
define void @NDRangeNull() nounwind readnone {
entry:
ret void
}
!opencl.kernels = !{!0, !2}
!opencl.global_address_space = !{!4}
!opencl.local_address_space = !{!5}
!opencl.constant_address_space = !{!6}
!0 = metadata !{void (i8 addrspace(1)*, i8 addrspace(2)*, i32)* @NDRangeHello, metadata !1}
!1 = metadata !{i32 16776960, i32 16776961, i32 16776963}
!2 = metadata !{void ()* @NDRangeNull, metadata !3}
!3 = metadata !{}
!4 = metadata !{i32 16776960}
!5 = metadata !{i32 16776961}
!6 = metadata !{i32 16776962}
More information about the cfe-dev
mailing list