[Mesa-stable] [PATCH v1.1 2/2] clover: fix getting scalar args api size

[Francisco Jerez]

Serge Martin <edb+mesa at 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.
>
Is there any guarantee that the alloc size of the type will match what
the CL API expects? (which is the only thing arg_api_size is used for
IIRC) Isn't it fully dependent on the data layout which is pretty much
up to the target?

> Cc: 12.0 <mesa-stable at lists.freedesktop.org>
> ---
>  src/gallium/state_trackers/clover/llvm/invocation.cpp | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> index 03487d6..bb0faaa 100644
> --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> @@ -469,10 +469,9 @@ namespace {
>  
>           // OpenCL 1.2 specification, Ch. 6.1.5: "A built-in data
>           // type that is not a power of two bytes in size must be
> -         // 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);
> +         // aligned to the next larger power of two.
> +         // This rule applies to built-in types only, not structs or unions."
> +         const unsigned arg_api_size = TD.getTypeAllocSize(arg_type);
>  
>           llvm::Type *target_type = arg_type->isIntegerTy() ?
>                 TD.getSmallestLegalIntType(mod->getContext(), arg_store_size * 8)
> -- 
> 2.5.5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 212 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-stable/attachments/20160603/93df8f78/attachment.sig>