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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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 ==
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
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
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:
>
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
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
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
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
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
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
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
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
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
28 matches
Mail list logo
