-
Notifications
You must be signed in to change notification settings - Fork 116
Remove use of inheritance from parallel-for bricks in SYCL backend #2136
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@mmichel11 Does we really have some benefits of using |
I will take a look at using |
Signed-off-by: Matthew Michel <[email protected]>
Signed-off-by: Matthew Michel <[email protected]>
Signed-off-by: Matthew Michel <[email protected]>
Signed-off-by: Matthew Michel <[email protected]>
Signed-off-by: Matthew Michel <[email protected]>
Signed-off-by: Matthew Michel <[email protected]>
Signed-off-by: Matthew Michel <[email protected]>
Signed-off-by: Matthew Michel <[email protected]>
Signed-off-by: Matthew Michel <[email protected]>
Signed-off-by: Matthew Michel <[email protected]>
Signed-off-by: Matthew Michel <[email protected]>
Signed-off-by: Matthew Michel <[email protected]>
…cl_fpga.h Signed-off-by: Matthew Michel <[email protected]>
Signed-off-by: Matthew Michel <[email protected]>
Signed-off-by: Matthew Michel <[email protected]>
Signed-off-by: Matthew Michel <[email protected]>
Signed-off-by: Matthew Michel <[email protected]>
96c8dcd
to
27e0932
Compare
Signed-off-by: Matthew Michel <[email protected]>
Signed-off-by: Matthew Michel <[email protected]>
Moving this to draft with the plan to close and do all review in PR #2165 unless there are objections. It prevents us from making changes in this PR that will just be removed in the subsequent. |
Closing, as this PR is no longer needed. |
This PR addresses #2023.
In #1976, parallel-for bricks were redesigned to have an inheritance relationship with a either a scalar or vector tuning base class in order to inherit compile-time tuning constants. This came with a downside of adding the user-provided range types to the class template of parallel-for bricks, complicating usage from the caller side as more templates must be provided when creating a brick.
This PR removes the use of inheritance from parallel-for bricks along with the range class templates with the following approach:
__can_vectorize
and__can_process_multiple_iters
.__can_vectorize
defines whether a vectorization path is provided. For some bricks (e.g.__custom_brick
for binary search) there is no benefit of providing a vectorization path.__can_process_multiple_iters
specifies whether a single item can safely process multiple strided iterations of input.__pfor_params
which queries the brick's static members to define vectorization and iters per item tuning parameters.__pfor_params
is passed to the brick when invoking the function call operator which includes vector sizes and whether vectorization should be enabled.Additionally, the
__scalar_path_impl
,__vector_path_impl
, and dispatchoperator()
design of the bricks have been replaced with twooperator()
definitions using SFINAE to define scalar and vector implementations dependent on whether the provided parameter instance is vectorizable.