Anton Lokhmotov
2011-Feb-21 09:45 UTC
[LLVMdev] [PATCH] OpenCL support - update on keywords
> > > > +enum OpenCLAddressSpace { > > > > + OPENCL_PRIVATE = 0, > > > > + OPENCL_GLOBAL = 1, > > > > + OPENCL_LOCAL = 2, > > > > + OPENCL_CONSTANT = 3 > > > > +};> -----Original Message----- > From: Villmow, Micah [mailto:Micah.Villmow at amd.com] > > Anton, > Would there be any issue with switching the ordering of constant and > local?Hi Micah, We'd rather not do that. First, this order follows the order of subsections in 6.5 of the OpenCL specification, with global described in 6.5.1, local in 6.5.2, constant in 6.5.3; private is described in 6.5.4 but it's also the default function-scope space which is 0. Second, we use the same order in our (non-LLVM) GPU backend. Best regards, Anton.
Villmow, Micah
2011-Feb-21 18:26 UTC
[LLVMdev] [PATCH] OpenCL support - update on keywords
The problem is that we use the ordering private, global, constant and local, and this is the same ordering that is used on Apple as well. As we already have OpenCL binaries out in public, making the change is problematic as we want to keep backward compatibility at all costs. Thanks, Micah> -----Original Message----- > From: Anton Lokhmotov [mailto:Anton.Lokhmotov at arm.com] > Sent: Monday, February 21, 2011 1:45 AM > To: Villmow, Micah; 'Peter Collingbourne' > Cc: llvmdev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu > Subject: RE: [PATCH] OpenCL support - update on keywords > > > > > > +enum OpenCLAddressSpace { > > > > > + OPENCL_PRIVATE = 0, > > > > > + OPENCL_GLOBAL = 1, > > > > > + OPENCL_LOCAL = 2, > > > > > + OPENCL_CONSTANT = 3 > > > > > +}; > > > -----Original Message----- > > From: Villmow, Micah [mailto:Micah.Villmow at amd.com] > > > > Anton, > > Would there be any issue with switching the ordering of constant > and > > local? > > Hi Micah, > > We'd rather not do that. First, this order follows the order of > subsections > in 6.5 of the OpenCL specification, with global described in 6.5.1, > local in > 6.5.2, constant in 6.5.3; private is described in 6.5.4 but it's also > the > default function-scope space which is 0. Second, we use the same order > in > our (non-LLVM) GPU backend. > > Best regards, > Anton. > > >
Villmow, Micah
2011-Feb-21 22:12 UTC
[LLVMdev] [PATCH] OpenCL support - update on keywords
Anton, We have discussed this internally a little bit. What about encoding the address space definition into the data layout string? That way various vendors can be compatible with each other. For example if the CL was generated by clang, it would have: target datalayout = "e-p:32:32:32-addr0:private-addr1:global-addr2:local-addr3:constant-i1:8:8-i8:8:8-i16:16:16" but our frontend would generate: target datalayout = "e-p:32:32:32-addr0:private-addr1:global-addr2:constant-addr3:local-i1:8:8-i8:8:8-i16:16:16" This information can be ignored on platforms that don't support multiple address spaces and would allow dynamic mapping so that the back end's do not need to have different modes for each different frontend. Micah> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Villmow, Micah > Sent: Monday, February 21, 2011 10:27 AM > To: Anton.Lokhmotov at arm.com; 'Peter Collingbourne' > Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] [PATCH] OpenCL support - update on keywords > > The problem is that we use the ordering private, global, constant and > local, and this is the same ordering that is used on Apple as well. As > we already have OpenCL binaries out in public, making the change is > problematic as we want to keep backward compatibility at all costs. > > Thanks, > Micah > > > -----Original Message----- > > From: Anton Lokhmotov [mailto:Anton.Lokhmotov at arm.com] > > Sent: Monday, February 21, 2011 1:45 AM > > To: Villmow, Micah; 'Peter Collingbourne' > > Cc: llvmdev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu > > Subject: RE: [PATCH] OpenCL support - update on keywords > > > > > > > > +enum OpenCLAddressSpace { > > > > > > + OPENCL_PRIVATE = 0, > > > > > > + OPENCL_GLOBAL = 1, > > > > > > + OPENCL_LOCAL = 2, > > > > > > + OPENCL_CONSTANT = 3 > > > > > > +}; > > > > > -----Original Message----- > > > From: Villmow, Micah [mailto:Micah.Villmow at amd.com] > > > > > > Anton, > > > Would there be any issue with switching the ordering of constant > > and > > > local? > > > > Hi Micah, > > > > We'd rather not do that. First, this order follows the order of > > subsections > > in 6.5 of the OpenCL specification, with global described in 6.5.1, > > local in > > 6.5.2, constant in 6.5.3; private is described in 6.5.4 but it's also > > the > > default function-scope space which is 0. Second, we use the same > order > > in > > our (non-LLVM) GPU backend. > > > > Best regards, > > Anton. > > > > > > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Anton Lokhmotov
2011-Feb-23 11:47 UTC
[LLVMdev] [PATCH] OpenCL support - update on keywords
Hi Micah,> The problem is that we use the ordering private, global, constant and > local, and this is the same ordering that is used on Apple as well. As > we already have OpenCL binaries out in public, making the change is > problematic as we want to keep backward compatibility at all costs.When you say 'binaries', I assume you mean 'LLVM bitcode'? (The ordering of enums in intermediate code wouldn't matter if the binaries were native x86 code.) I believe the OpenCL specification provides no guarantees whatsoever regarding compatibility of binaries: neither between binaries from different vendors, nor between binaries from the same vendor. So IMO users who try to avoid runtime compilation and port binaries between different versions of AMD SDK actually ask for trouble. (This doesn't mean I don't appreciate your concern, however.)> We have discussed this internally a little bit. What about encoding > the address space definition into the data layout string? That way > various vendors can be compatible with each other.This encoding would clearly not be enough for full binary compatibility, and it would quite solve the problem with binaries that are already out in public. (Of course, you can assume that if a binary doesn't include the address space related string, it's an old one using the private-global-constant-local ordering.) I think that instead of allowing this customisation (which will allow an unbounded number of mappings of the address spaces to integers) we should declare the most sensible order "standard" or "canonical", and allow the backends to query the binary to see if it is in the standard form. Does it make sense? Thus, we are getting back to the problem of defining the standard form of representing OpenCL C programs in LLVM-IR. Soon I'll start sending proposals for representing different features and solicit feedback from the list. Best regards, Anton.