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
Anastasia accepted this revision.
Anastasia added a comment.
Your code comment seem to describe the issue quite well. Even though I am still
inclined towards keeping the address spaces as long as possible and only
converting into physical memory segments on the backend really. I believe there
a
yaxunl added a comment.
In https://reviews.llvm.org/D26157#589033, @pekka.jaaskelainen wrote:
> The uses for the OpenCL logical address spaces that I know of are:
>
> 1. to differentiate local kernel arguments as their memory allocation is
> different (per WG if parallel WGs)
> 2. alias analysis
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
Anastasia added a comment.
In https://reviews.llvm.org/D26157#586867, @pekka.jaaskelainen wrote:
> 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 w
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
Anastasia added a comment.
I am wondering whether returning the strings with source level information
would be an option instead? But yes this MD are OpenCL specific indeed. I am
just not sure whether putting hard-coded arbitrary numbers would not cause any
confusions in the future. I feel that
yaxunl added a comment.
The enum for address space is not necessarily bound to SPIR as long as the
runtime knows it.
Since most OpenCL runtime already uses that definition (if they use clang as
compiler), I don't see a reason to change that. I doubt this metadata can be
used for anything else
Anastasia added a comment.
In https://reviews.llvm.org/D26157#586764, @yaxunl wrote:
> One purpose of kernel arg info metadata is to be passed to OpenCL runtime to
> fulfill clGetKernelArgInfo queries.
> (https://www.khronos.org/registry/cl/sdk/1.2/docs/man/xhtml/clGetKernelArgInfo.html).
> As
yaxunl added a comment.
One purpose of kernel arg info metadata is to be passed to OpenCL runtime to
fulfill clGetKernelArgInfo queries.
(https://www.khronos.org/registry/cl/sdk/1.2/docs/man/xhtml/clGetKernelArgInfo.html).
As such, the address space id needs to be at source level instead of IR
Anastasia added a comment.
> Is there nowadays such a thing as "standard OpenCL logical AS IDs" which
> could be retained down to code gen? I must say I haven't checked the current
> situation here. It used to be that the logical ids are assumed to be
> converted to the target ones already in C
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
bader added a comment.
@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 for the
machines with 'flat' address space model.
On the other hand I would exp
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
yaxunl added a comment.
LGTM. Thanks.
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/cfe-commits
Anastasia added a comment.
It looks good generally. My only concern here if anyone could use this MD
expecting target AS values which correspond to those put in the IR itself. On
the other hand clGetKernelArgInfo is supposed to be used for obtaining the
information about the original source whi
16 matches
Mail list logo