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

[Matt Arsenault]

On 04/22/2014 05:22 PM, Jan Vesely wrote:
> On Tue, 2014-04-22 at 14:40 -0700, Matt Arsenault wrote:
>> On 04/22/2014 02:35 PM, Tom Stellard wrote:
>>> On Mon, Apr 21, 2014 at 10:02:27PM -0400, Jan Vesely wrote:
>>>> Hi,
>>>>
>>>> I ran into a problem caused by this part of the OCL specs (6.1.5
>>>> Alignment of Types):
>>>> "For 3-component vector data types, the size of the data type is 4 *
>>>> sizeof(component)."
>>>>
>>>> and the corresponding part of Khronos cl_platform.h (with all types, not
>>>> just float):
>>>> /* cl_float3 is identical in size, alignment and behavior to cl_float4.
>>>> See section 6.1.5. */
>>>> typedef  cl_float4  cl_float3;
>>>>
>>>> So when I try to run kernel that takes 3 element vectors as arguments I
>>>> get 'invalid arg size' error.
>>>>
>>>> Not sure whether this is best solved in clang, libclc or clover. I tried
>>>> changing float3 to have 4 elements in libclc, it caused clang to
>>>> complain in thousand places. I don't think this can be handled cleanly
>>>> in clang, unless we add something like __attribute__((padding)).
>>>>
>>>> I have attached a workaround that I use now.
>>>>
>>> You may want to ask this question on the pocl mailing list as they
>>> have likely solved this issue already.  Ideally, TD.getTypeStoreSize
>>> would return the correct value.  Also, maybe look at the DataLayout
>>> description for R600 and see if there is a way to specify the
>>> correct type size.
>>>
>>> -Tom
>> 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.