See: #2595 (review)
Our current harness functions for programs and kernels are confusing. We should clean them up to simplify development and maintenance in the future.
Some specific suggestions:
- The harness function
create_single_kernel_helper_create_program_for_device is never used and can be removed.
- The harness function
create_single_kernel_helper_with_build_options just calls the harness function create_single_kernel_helper. We should remove create_single_kernel_helper_with_build_options and just call create_single_kernel_helper directly, instead.
- There are two overloads of
create_single_kernel_helper_create_program: one is a version called directly by tests and another is an internal helper function only used within the harness. We should name the functions differently to disambiguate their uses.
- Build options are handled subtly differently in
create_single_kernel_helper and create_single_kernel_helper_create_program: in create_single_kernel_helper, the build options are modified to add the highest supported OpenCL C version supported by all device in the context (assuming no other OpenCL C version is specified explicitly), whereas in create_single_kernel_helper_create_program the build options are left unmodified. Is this intentional? If so, we should find a way to make this difference clear.
It would be fine to do this cleanup in multiple steps, since (1), (2), and (3) are fairly straightforward, whereas (4) may require more thought and discussion.
See: #2595 (review)
Our current harness functions for programs and kernels are confusing. We should clean them up to simplify development and maintenance in the future.
Some specific suggestions:
create_single_kernel_helper_create_program_for_deviceis never used and can be removed.create_single_kernel_helper_with_build_optionsjust calls the harness functioncreate_single_kernel_helper. We should removecreate_single_kernel_helper_with_build_optionsand just callcreate_single_kernel_helperdirectly, instead.create_single_kernel_helper_create_program: one is a version called directly by tests and another is an internal helper function only used within the harness. We should name the functions differently to disambiguate their uses.create_single_kernel_helperandcreate_single_kernel_helper_create_program: increate_single_kernel_helper, the build options are modified to add the highest supported OpenCL C version supported by all device in the context (assuming no other OpenCL C version is specified explicitly), whereas increate_single_kernel_helper_create_programthe build options are left unmodified. Is this intentional? If so, we should find a way to make this difference clear.It would be fine to do this cleanup in multiple steps, since (1), (2), and (3) are fairly straightforward, whereas (4) may require more thought and discussion.