pxli168 added inline comments.

================
Comment at: lib/CodeGen/CGOpenCLRuntime.cpp:108
@@ +107,3 @@
+    PipeTy = llvm::PointerType::get(llvm::StructType::create(
+      CGM.getLLVMContext(), "opencl.pipe_t"), PipeAddrSpc);
+  }
----------------
pekka.jaaskelainen wrote:
> I'm not sure if touching the built-in fingerprints for this is a good idea. 
> It might lead to problems and confusion. Cannot one pass pipes as arguments 
> to user functions too? Are the fingerprints of those functions then modified 
> accordingly? It might become messy.
> 
> Because the packet size is known at host side, the pipes can be implemented 
> as structs which holds the packet size as one of the member variables. The 
> problem with this approach is how to exploit wider reads/writes instead of a 
> scalar read/write loop + unpack/pack in case of vector datatypes. 
> 
> If the size is known only at runtime, one cannot easily generate vector 
> reads/writes even if the element is a vector datatype and it would be 
> efficient to keep the packet in a vector register as long as possible. For 
> helping this I'd add a metadata which can be utilized at compile time to make 
> reading/writing from the pipe faster.  But in a way that is already an 
> optimization, not a requirement, to make pipes work.
> 
> The reading itself is platform dependent as the pipe can be even a hardware 
> FIFO accessed using special instructions.
This is what I'm worry about, I don't think we need to give much information 
about an opaque type in OpenCL.

Actually we can get the element type from the metadata, and I think we can 
leave the optimization to the backend and let platform to choose which way to 
use for read/write pipe.

And I think the built-in function support for the pipe in OpenCL-C is not 
necessary in the clang, what do you think? Though it can do some check in Sema 
check, they can also be done in some llvm pass in backend. If the built-in is 
really needed, I will send another patch based on this included built-in 
support for pipe.

Thank you.


http://reviews.llvm.org/D15603



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to