Anastasia added inline comments.

================
Comment at: clang/docs/LanguageExtensions.rst:1804
 
+``__cl_clang_allow_unsafe_kernel_parameters``
+---------------------------------------------
----------------
How about `__cl_clang_unsafe_kernel_parameters` to match the other extension 
naming scheme? Or we could use `__cl_clang_non_portable_kernel_parameters`, 
`__cl_clang_non_portable_kernel_parameter_types` to be more specific regarding 
the kind of safety that we allow to break?


================
Comment at: clang/docs/LanguageExtensions.rst:1807
+
+With this extension it is possible to define kernel functions whose arguments
+do not follow the requirements using regular OpenCL extension pragma mechanism
----------------



================
Comment at: clang/docs/LanguageExtensions.rst:1812
+
+This is not conformant behavior and it can only be used portably when the
+arguments don't get passed across the host/device boundary, or if the compilers
----------------



================
Comment at: clang/docs/LanguageExtensions.rst:1813
+This is not conformant behavior and it can only be used portably when the
+arguments don't get passed across the host/device boundary, or if the compilers
+used for both host and device give the same layout.
----------------



================
Comment at: clang/docs/LanguageExtensions.rst:1814
+arguments don't get passed across the host/device boundary, or if the compilers
+used for both host and device give the same layout.
+
----------------



================
Comment at: clang/docs/LanguageExtensions.rst:1823
+  #pragma OPENCL EXTENSION __cl_clang_allow_unsafe_kernel_parameters : enable
+    non_pod_type b,
+    global non_standard_layout_type *c,
----------------
Let's add declarations of such types along in the example. 


================
Comment at: clang/lib/Sema/SemaDecl.cpp:8651
 static OpenCLParamType getOpenCLKernelParameterType(Sema &S, QualType PT) {
+  if (PT->isDependentType())
+    return InvalidKernelParam;
----------------
I would rather add an assert for this because we should not ever reach this 
function for the dependent types?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101168/new/

https://reviews.llvm.org/D101168

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

Reply via email to