OpenCL C "long" should always have 64 bits

Erik Schnetter schnetter at gmail.com
Tue Sep 3 13:04:16 PDT 2013


On 2013-09-03, at 14:37 , Michele Scandale <michele.scandale at gmail.com> wrote:

> On 09/03/2013 07:53 PM, Tom Stellard wrote:
>> On Tue, Sep 03, 2013 at 01:34:50PM -0400, Erik Schnetter wrote:
>>> Yes, R600 defines a "good" address space map.
>>> 
>>> My patch currently overrides the target-specific address space maps...
>>> 
>>> Instead of doing so, I think the right approach is to define a default address space map that already does the right thing for OpenCL and CUDA. This makes sense since address spaces seem currently defined for OpenCL and CUDA only, i.e. they won't be used by standard C/C++. The targets can then override the default (which they already do).
>>> 
>> 
>> Does the rest of this patch depend on resolving the mangling issues with
>> address spaces?  If not, can we split the address space map out into a
>> separate patch and commit the rest of the changes?  The OpenCL type
>> changes are very useful, and I wouldn't want the address space mapping
>> discussions to prevent them from being committed.
> 
> I agree. The problems of type size is orthogonal from mangling and address
> spaces. I know that it's all related and to have everything working we would
> need a global solution, but still being orthogonal they should be solved in
> different patches.
> 
> This part related to type size is first step that fix a quite big lack in the
> support of OpenCL.
> 
> Then the mangling can be fixed (I'm still waiting for feedback to know if the
> last proposed patch can be fine or not to be committed).
> 
> The last part about address space information requires also modification in the
> middle end (I am working on this... soon a proposed patch for metadata handling).


Yes, these issues are unrelated. (However, I still have the address space parts in my source tree to be able to compile and test.)

Here is an updated patch against the trunk (previous patch was against 3.3 release branch), with the address space handling removed. I also add two test cases.

-erik

-- 
Erik Schnetter <schnetter at gmail.com>
http://www.perimeterinstitute.ca/personal/eschnetter/

My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from http://pgp.mit.edu/.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenCL-long-trunk.diff
Type: application/octet-stream
Size: 3212 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130903/b27883bc/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: type-sizes.cl
Type: application/octet-stream
Size: 592 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130903/b27883bc/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signed-char.cl
Type: application/octet-stream
Size: 162 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130903/b27883bc/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130903/b27883bc/attachment.sig>


More information about the cfe-commits mailing list