[cfe-dev] sizeof(long) in OpenCL C

Michele Scandale michele.scandale at gmail.com
Mon Sep 2 07:19:13 PDT 2013


On 09/02/2013 03:22 PM, David Tweed wrote:
> Hi,
> 
> | Picking 'size_t' as example: on a 64bit target I would expect that 'size_t' will
> | be mapped to an unsigned 64bit builtin integer type. If I declare LongWidth =
> | LongLongWidth = 64 then both 'unsigned long' and 'unsigned long long' would be
> | valid choice for 'size_t'. Expressing the relationship in a indirect way then
> | the definition of implementation defined types is not affected by the potential
> | changes that OpenCL language definition may impose respect to the choice done
> | for the C compiler.
> 
> Ah, I see. I think I probably used an ambiguous term in "implementation defined" that caused confusion. All I basically mean was that we can't assume that there's only one implementation of OpenCL on a given platform (pocl on platforms with existing vendor OpenCL implementations illustrates that, and also illustrates that the term "vendor" that's commonly used can be misleading): as a trivial example, one could easily have a 64-bit platform that can run both 64- and 32-bit userspace APIs and then have one implementor's OpenCL implementation using 32-bit pointers and another implementor's implementation using 64-bit pointers. As such, the pointer size decided to be supported is not a property just of the platform, but also the OpenCL implementation.
> 
> Maintaining this flexibility is going to be particularly important if there's a push to encourage OpenCL implementors to use as much OSS clang infrastructure as possible.

Specific for OpenCL a common target option could be the way to require "short
pointers", but targets should specify if this mode is supported (I think that
LLVM backends should be aware of this in order to handle correctly pointer loads).

If this kind of flexibility is required beyound the scope of OpenCL I think this
is more or less equivalent to an ABI variant, so targets should still support
this ABI variant and LLVM backends should still explicitly support this.

Regards,
-Michele

> Cheers,
> Dave
> 
> 
> -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.
> 
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782
> 




More information about the cfe-dev mailing list