Re: TCE target nonconforming definition of long long and intmax_t

Hi Aaron, Indeed the 32b TCE target is not fully compliant in this aspect; its 64b emulation support is not complete, therefore we advertise only these 32b limits. We have an in-progress 64b target where the limits are 64b, but it's not upstreamed yet. Yes, TCE target is still maintained, but it

[PATCH] D26157: [OpenCL] always use SPIR address spaces for kernel_arg_addr_space MD

pekka.jaaskelainen closed this revision. pekka.jaaskelainen added a comment. Committed in r286819. Repository: rL LLVM https://reviews.llvm.org/D26157 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/l

[PATCH] D26157: [OpenCL] always use SPIR address spaces for kernel_arg_addr_space MD

pekka.jaaskelainen added a comment. > target architecture). So if there are no memory segments, nothing can be done > to optimize for this and therefore providing > the "fake" segment information doesn't seem to be useful? I am just trying > to understand the use case. The uses for the OpenCL

[PATCH] D26157: [OpenCL] always use SPIR address spaces for kernel_arg_addr_space MD

pekka.jaaskelainen added a comment. Indeed, it requires wider scale discussion to get it right, and e.g. to pass the info to AA. But to be honest, I think OpenCL and CUDA are still considered 'minority' languages in Clang/LLVM which makes me usually lean towards least intrusive implementation s

[PATCH] D26157: [OpenCL] always use SPIR address spaces for kernel_arg_addr_space MD

pekka.jaaskelainen added a comment. In https://reviews.llvm.org/D26157#585688, @bader wrote: > @pekka.jaaskelainen, I have related question: what is the problem with > retaining OpenCL address space information in LLVM IR? > My understanding is that target CodeGen can ignore this information fo

[PATCH] D26157: [OpenCL] always use SPIR address spaces for kernel_arg_addr_space MD

pekka.jaaskelainen added a comment. Thanks. @tstellarAMD OK to commit for 3.9.1 as well? Repository: rL LLVM https://reviews.llvm.org/D26157 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cf

Re: [PATCH] D20249: [OpenCL] Hierarchical/dynamic parallelism - enqueue kernel in OpenCL 2.0

pekka.jaaskelainen added a comment. LGTM, FWIW. http://reviews.llvm.org/D20249 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D17596: [OpenCL] Add ocl and spir version for spir target

pekka.jaaskelainen added inline comments. Comment at: test/CodeGenOpenCL/spir_version.cl:15 @@ +14,2 @@ +// CL20: !opencl.ocl.version = !{[[SPIR:![0-9]+]]} +// CL20: [[SPIR]] = !{i32 2, i32 0} Can you test 'spir64' too? http://reviews.llvm.org/D17596

Re: [PATCH] D16876: [OpenCL] Refine pipe builtin support

pekka.jaaskelainen accepted this revision. pekka.jaaskelainen added a comment. This revision is now accepted and ready to land. In http://reviews.llvm.org/D16876#359781, @Anastasia wrote: > @Pekka, do you have any more comments? Nope. Looking forward to finally implementing proper pipe support

Re: [PATCH] D16928: [OpenCL] Apply missing restrictions for Blocks in OpenCL v2.0

pekka.jaaskelainen added inline comments. Comment at: test/SemaOpenCL/invalid-func.cl:6 @@ +5,2 @@ +void foo(int, ...); // expected-error{{OpenCL does not allow variadic arguments}} +int printf(const char *, ...); I wonder should we check for the fingerprint too

Re: [PATCH] D16686: [OpenCL] Generate metadata for opencl_unroll_hint attribute

pekka.jaaskelainen accepted this revision. pekka.jaaskelainen added a comment. LGTM. http://reviews.llvm.org/D16686 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16040: [OpenCL] Refine OpenCLImageAccessAttr to OpenCLAccessAttr

pekka.jaaskelainen accepted this revision. pekka.jaaskelainen added a comment. Otherwise LGTM. Comment at: lib/Sema/SemaChecking.cpp:267 @@ -266,3 +266,3 @@ /// Returns OpenCL access qual. // TODO: Refine OpenCLImageAccessAttr to OpenCLAccessAttr since pipe can use // it too

Re: r258782 - Recommit: R258773 [OpenCL] Pipe builtin functions

Hi, On 01/28/2016 09:25 PM, Hans Wennborg via cfe-commits wrote: > I don't think we have a specific code owner for OpenCL in Clang, which > means Richard is the owner. FYI, in a separate thread, there's an attempt to elect Anastasia as one. -- Pekka _

Re: [PATCH] D15914: [OpenCL] Pipe builtin functions

pekka.jaaskelainen added a comment. > @Pekka, do you think it would make sense to include a description of the new > OpenCL features in the release note too? Or shall we wait for the completion > of OpenCL 2.0 support (hopefully in next release)? Could do both as well I > guess. :) Yes I th

Re: [PATCH] D15914: [OpenCL] Pipe builtin functions

pekka.jaaskelainen accepted this revision. pekka.jaaskelainen added a comment. LGTM too. Good job. You can try and ask the release manager if you can sneak it in. It's rather container patch so there might be a chance, but I don't know the policy at this stage of the release. http://reviews.ll

Re: [PATCH] D15914: [OpenCL] Pipe builtin functions

pekka.jaaskelainen added a comment. OK. Seems the LLVM 3.8 branching was done, it might be hard to get this in, but should we try and ask the release manager? Comment at: lib/CodeGen/CGBuiltin.cpp:1981 @@ +1980,3 @@ + const char *Name = + (BuiltinID == Builtin::BI

Re: [PATCH] D15914: [OpenCL] Pipe builtin functions

pekka.jaaskelainen added inline comments. Comment at: lib/CodeGen/CGBuiltin.cpp:2033 @@ +2032,3 @@ + *Arg1 = EmitScalarExpr(E->getArg(1)); +llvm::Type *ReservedIDTy = ConvertType(getContext().OCLReserveIDTy); + Anastasia wrote: > pekka.jaaskelainen wr

Re: [PATCH] D15914: [OpenCL] Pipe builtin functions

pekka.jaaskelainen added inline comments. Comment at: lib/CodeGen/CGBuiltin.cpp:2033 @@ +2032,3 @@ + *Arg1 = EmitScalarExpr(E->getArg(1)); +llvm::Type *ReservedIDTy = ConvertType(getContext().OCLReserveIDTy); + Anastasia wrote: > Why do we need to mod

Re: [PATCH] D16047: [OpenCL] Add Sema checks for OpenCL 2.0

pekka.jaaskelainen added inline comments. Comment at: lib/Sema/SemaDecl.cpp:5733 @@ +5732,3 @@ + +#if 0 + Is this intentionally included in the patch? Comment at: lib/Sema/SemaDecl.cpp:6759 @@ +6758,3 @@ + +#if 0 + // OpenCL v2.0 s6.9.b ---

Re: [PATCH] D15914: [OpenCL] Pipe builtin functions

pekka.jaaskelainen added a comment. In http://reviews.llvm.org/D15914#322917, @pxli168 wrote: > By the way, I just got the access to the llvm svn, can I just commit the pipe > type patch directly as I see you all accepted it. Or I should send it to the > cfe-commit first? I'm afraid we won'

Re: [PATCH] D15914: [OpenCL] Pipe builtin functions

pekka.jaaskelainen added a comment. I wonder could we squeeze this in before the next week's LLVM 3.8 branching? It would be great. Comment at: lib/CodeGen/CGBuiltin.cpp:2033 @@ +2032,3 @@ +else if (BuiltinID == Builtin::BIwork_group_reserve_write_pipe) + Name = "_Z29w

Re: [PATCH] D15603: [OpenCL] Pipe type support

pekka.jaaskelainen 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); + } pxli168 wrote: > pekka.jaaskelai

Re: [PATCH] D15603: [OpenCL] Pipe type support

pekka.jaaskelainen 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); + } I'm not sure if touching the bui

Re: [Patch][OpenCL] Custom atomic Builtin check ignores address space of a non-atomic pointer

Hi Anastasia, Still LGTM. Pekka On 16.12.2015 16:42, Anastasia Stulova wrote: Hi Pekka, Re-attaching as a full patch again as something went wrong earlier with the diff wrapping in the email. Thanks, Anastasia -Original Message- From: cfe-commits [mailto:cfe-commits-boun...@lists.l

Re: [PATCH] D14441: [OpenCL] Pipe types support.

pekka.jaaskelainen added a comment. Nice! I will keep on trying to help by reviewing patches whenever time allows. http://reviews.llvm.org/D14441 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/

Re: [PATCH] D14441: [OpenCL] Pipe types support.

pekka.jaaskelainen added a comment. Is this still waiting for some updates? http://reviews.llvm.org/D14441 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D14441: [OpenCL] Pipe types support.

pekka.jaaskelainen accepted this revision. This revision is now accepted and ready to land. Comment at: include/clang/Serialization/ASTBitCodes.h:911 @@ +910,3 @@ + TYPE_ADJUSTED = 42, + /// \brief An PipeType record. + TYPE_PIPE = 43 -

Re: [PATCH] D14441: [OpenCL] Pipe types support.

pekka.jaaskelainen requested changes to this revision. pekka.jaaskelainen added a comment. This revision now requires changes to proceed. Only small issues found, plus it could use some more test cases. Comment at: include/clang/AST/TypeLoc.h:2049 @@ +2048,3 @@ + SourceRange ge

Re: [PATCH] D13349: [OpenCL] Casting boolean to an integer vector in OpenCL should set all bits if boolean is true

pekka.jaaskelainen added a comment. OK now. http://reviews.llvm.org/D13349 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D13349: [OpenCL] Casting boolean to an integer vector in OpenCL should set all bits if boolean is true

pekka.jaaskelainen added a subscriber: pekka.jaaskelainen. pekka.jaaskelainen accepted this revision. pekka.jaaskelainen added a reviewer: pekka.jaaskelainen. This revision is now accepted and ready to land. Comment at: lib/CodeGen/CGExprScalar.cpp:820 @@ -809,3 +819,3 @@ Qua

Re: [Patch][OpenCL] Custom atomic Builtin check ignores address space of a non-atomic pointer

LGTM. Related to it: There has been so many getPointerTo() issues with multi-AS in the past that I wonder if it'd be time to drop the default value from it, and go through all the places where it's called with the default AS, thus breaking multi-AS. Might be a worthwhile job to do at some point.

Re: [PATCH] D13168: [OpenCL] OpenCL2.0 - Apply default address space rules

pekka.jaaskelainen requested changes to this revision. This revision now requires changes to proceed. Comment at: lib/Sema/SemaType.cpp:6166 @@ -6166,2 +6165,3 @@ attr.setUsedAsTypeAttr(); + hasOpenCLAddressSpace = true; break; Should this be be

Re: [PATCH] D13105: [OpenCL] Enable program scope variables for OpenCL2.0

pekka.jaaskelainen requested changes to this revision. pekka.jaaskelainen added a comment. This revision now requires changes to proceed. Could only find style nitpicks in this one. Comment at: include/clang/Basic/DiagnosticSemaKinds.td:7473 @@ -7470,3 +7472,3 @@ def err_opencl

Re: [PATCH] D12855: [OpenCL] Add new types for OpenCL 2.0.

pekka.jaaskelainen added a comment. We are interested in the pipe. I don't think it makes sense to increase the patch size by running the stylifier. Perhaps in an additional patch after this? http://reviews.llvm.org/D12855 ___ cfe-commits mailing

Re: [PATCH] D12855: [OpenCL] Add new types for OpenCL 2.0.

pekka.jaaskelainen accepted this revision. pekka.jaaskelainen added a comment. This revision is now accepted and ready to land. The patch seems straightforward enough. BTW does someone know if anyone has worked on the 'pipe' qualifier? Comment at: lib/Serialization/ASTCommon.cp

Re: [PATCH] D10586: Add HSAIL support

pekka.jaaskelainen added a comment. Is there a matching HLC-HSAIL branch for the latest version of the patch? It doesn't work with with hsail-stable-3.7 anymore. http://reviews.llvm.org/D10586 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

Re: [PATCH] D12378: [OpenCL] Improve diagnostics detecting implicit vector conversion.

pekka.jaaskelainen added a subscriber: pekka.jaaskelainen. pekka.jaaskelainen accepted this revision. pekka.jaaskelainen added a reviewer: pekka.jaaskelainen. pekka.jaaskelainen added a comment. This revision is now accepted and ready to land. Perhaps the assert() is unneccessary, but otherwise LG