-
Notifications
You must be signed in to change notification settings - Fork 787
[SYCL] [FPGA] Update handler of variadic template argument list in fpga_utils.hpp to support more types other than int32_t #3957
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Is there any test checking for that? |
Not yet, the upcoming latency control header change will use other types. But as for this patch, there's no functional difference in fpga.lsu.hpp. |
Yes. Otherwise it's quite likely that this functionality might be unintentionally broken by future patches (e.g. code refactoring). |
Sure, could you point me where to add the test? I knew there was a sycl/test/fpga_tests folder, but seems it's gone now. |
Here are common guidelines: https://github.com/intel/llvm/blob/sycl/CONTRIBUTING.md#tests-development |
It seems we need a test which verifies produced IR here. @sergey-semenov Could you please confirm? |
I think using |
If the only test we need here is a cpp file that includes this header, where should I put the test file? I don't see the guidelines link above covers it. |
|
I have created a new test - sycl/test/fpga_tests/arbitrary_template_arg.cpp. It's not a static_assert check but a host run check. |
I would prefer to have the test similar to |
It makes sense to remove the compiled test :). As for the test I added, I want to check both type support (int and enum class) and arbitrary order support of template argument list (users don't have to specify all template arguments, and template arguments can be specified in arbitrary order). A run check covers both ends. |
I'm not quire sure how the runtime check here does anything a compile-time check wouldn't be able to do. Something like this should check the same behaviour as what you have now.
|
Apply static_assert compile-time check.
Changed my test to use compile-time static_assert. |
Patch intel#3957 introduces `_statically_coalesce_val` in fpga_lsu.cpp like this: ``` _GetValue<statically_coalesce_impl<1>, _mem_access_params...>::value; ``` During merge conflict resolution in intel#4014 it was change accidentally to ``` _GetValue<statically_coalesce_impl<0>, _mem_access_params...>::value; ``` Restoring the right value.
#4206) Patch #3957 introduces `_statically_coalesce_val` in fpga_lsu.cpp like this: ``` _GetValue<statically_coalesce_impl<1>, _mem_access_params...>::value; ``` During merge conflict resolution in #4014 it was change accidentally to ``` _GetValue<statically_coalesce_impl<0>, _mem_access_params...>::value; ``` Restoring the right value.
intel#4206) Patch intel#3957 introduces `_statically_coalesce_val` in fpga_lsu.cpp like this: ``` _GetValue<statically_coalesce_impl<1>, _mem_access_params...>::value; ``` During merge conflict resolution in intel#4014 it was change accidentally to ``` _GetValue<statically_coalesce_impl<0>, _mem_access_params...>::value; ``` Restoring the right value.
…ment list The previous patch intel#3957 was a prerequisite change for the upcoming FPGA latency control feature. Revert due to a late change to the proposed use model API.
This patch is a prerequisite for the upcoming FPGA latency control feature.