Francisco Jerez <curroje...@riseup.net> writes:
> Serge Martin <edb+m...@sigluy.net> writes:
>
>> This fix getting the size of a struct arg. vec3 types still work ok.
>> Only buit-in args need to have power of two alignment, getTypeAllocSize
>> reports the correct size.
>> ---
>> src/gallium/state_trackers/clover/llvm/invocation.cpp | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
>> b/src/gallium/state_trackers/clover/llvm/invocation.cpp
>> index 03487d6..9af51539 100644
>> --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
>> +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
>> @@ -472,7 +472,8 @@ namespace {
>> // aligned to the next larger power of two". We need this
>> // alignment for three element vectors, which have
>> // non-power-of-2 store size.
>> - const unsigned arg_api_size =
>> util_next_power_of_two(arg_store_size);
>> + const unsigned arg_api_size = arg_type->isStructTy() ?
>> + arg_store_size : util_next_power_of_two(arg_store_size);
>>
> Hm... Isn't this still going to be broken if you pass a struct argument
> to a kernel function and the alignment of any of the struct members
> doesn't match the target-specific data layout? Not sure we can fix this
> sensibly without requiring the target's data layout to match the CL API
> exactly. Any suggestions Tom?
>Unless someone has a better plan, I suggest we roll back to v1.1 of this patch and call it a back-end data layout bug if the expected alignment or size of a kernel argument type doesn't match the requirements set by the CL spec. >> llvm::Type *target_type = arg_type->isIntegerTy() ? >> TD.getSmallestLegalIntType(mod->getContext(), arg_store_size >> * 8) >> -- >> 2.5.5
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
