[cfe-dev] [Mesa-dev] 3 element vectors in opencl 1.1+

[Erik Schnetter]

On Apr 24, 2014, at 0:30 , Jan Vesely <jan.vesely at rutgers.edu> wrote:

> On Wed, 2014-04-23 at 19:49 +0200, Francisco Jerez wrote:
>> Jan Vesely <jan.vesely at rutgers.edu> writes:
>> 
>>> On Tue, 2014-04-22 at 17:50 -0700, Matt Arsenault wrote:
>>> <snip>
>>> 
>>>>>> I think this is what v96:128 is for
>>>>> according to [0], it specifies only alignment, not size. I could not
>>>>> find an __attribute__ that would change size either.
>>>>> 
>>>>> It should be possible to have ADMGPUDataLayout: public DataLayout class
>>>>> that would intercept the call and fix the reported value, but I think it
>>>>> would only move the hack to different place.
>>>>> 
>>>>> I have added pocl-devel list as suggested.
>>>>> 
>>>>> regards,
>>>>> Jan
>>>>> 
>>>>> [0]http://llvm.org/docs/LangRef.html#data-layout
>>>>> 
>>>> 
>>>> Only the size in memory matters, which is what the required alignment 
>>>> specifies. DataLayout::getTypeAllocSize accounts for the alignment, but 
>>>> getTypeStoreSize does not. I actually thought this was half of what 
>>>> getTypeStoreSize was for, but it turns out it isn't.
>>> 
>>> hm, I always thought that alignment only puts restrictions on starting
>>> address and using padding was just a tool to do the job.
>>> 
>>> anyway, thanks for the hint, using getTypeAllocSize works nicely.
>>> since we are allocating space in the argument vector I think
>>> getAllocSize is the right function to use.
>>> 
>>> I'll post a patch.
>>> 
>> 
>> I don't think that using getTypeAllocSize() instead of
>> getTypeStoreSize() to calculate clover::argument::size would be a
>> satisfactory solution.  By doing that you'd redefine the API argument
>> size exposed to the host for *all* argument types to be the
>> device-dependent aligned size, which is definitely not what you want.
> 
>> AFAIK 3-element vectors are an exception because they are the only types
>> that are defined to have a different API size from their actual usable
>> size, so they probably deserve special handling in invocation.cpp (as
>> you did in your first patch).  As the API size is target-independent I
>> don't think that the fix belongs in Clang or LLVM, Clover is likely at
>> fault.
> 
> The way I understood the ch 6.1.5 is that both API and OpenCL C 3
> element vectors are required to be 4*sizeof(component). So a
> sizeof(float3) == sizeof(cl_float3) == 16, and should be both host and
> target independent. That's why clang (or more precisely libclc) looked
> like a correct place.
> 
> I understand that target device can have stricter alignment rules, but I
> don't see how it can have different type sizes (my reading of the specs
> is that these are binding for the target as well).

OpenCL specifies the alignment of types; this is not up to the target. For the basic types, the alignment is their size.

-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: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140424/21843d09/attachment.sig>