> -----Original Message-----
> From: Beignet [mailto:[email protected]] On Behalf Of
> [email protected]
> Sent: Thursday, March 9, 2017 5:41 PM
> To: [email protected]
> Cc: Yan Wang <[email protected]>
> Subject: [Beignet] [PATCH v2] Provide more possible candidate of load/store as
> possible.
>
> From: Yan Wang <[email protected]>
>
> Avoid searching range too small in some case like vector of float.
> It will lead more load/store merged for improving perforamnce.
>
> Signed-off-by: Yan Wang <[email protected]>
> ---
> backend/src/llvm/llvm_loadstore_optimization.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/backend/src/llvm/llvm_loadstore_optimization.cpp
> b/backend/src/llvm/llvm_loadstore_optimization.cpp
> index e797e98..e569a8e 100644
> --- a/backend/src/llvm/llvm_loadstore_optimization.cpp
> +++ b/backend/src/llvm/llvm_loadstore_optimization.cpp
> @@ -180,7 +180,7 @@ namespace gbe {
> BasicBlock::iterator J = start;
> ++J;
>
> - unsigned maxLimit = maxVecSize * 8;
> + unsigned maxLimit = std::max(maxVecSize * 8, 150u);
Could you give some performance number against some known benchmarks?
Please select some complex enough OpenCL kernel. Maybe luxmark? Darktable?
How it would benefit the runtime performance and how much it would hurt the
compile-time performance?
So we could know whether the change is reasonable.
Thanks!
Ruiling
> bool reordered = false;
>
> for(unsigned ss = 0; J != E && ss <= maxLimit; ++ss, ++J) {
> --
> 2.7.4
>
> _______________________________________________
> Beignet mailing list
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/beignet
_______________________________________________
Beignet mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/beignet
