Skip to content

[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

Merged
merged 13 commits into from
Jul 9, 2021

Conversation

shuoniu-intel
Copy link
Contributor

@shuoniu-intel shuoniu-intel commented Jun 18, 2021

This patch is a prerequisite for the upcoming FPGA latency control feature.

@shuoniu-intel shuoniu-intel changed the title Update fpga_utils.hpp [SYCL] [FPGA] Update LSU builtins template to allow types other than int32_t Jun 18, 2021
@shuoniu-intel shuoniu-intel changed the title [SYCL] [FPGA] Update LSU builtins template to allow types other than int32_t [SYCL] [FPGA] Update fpga_utils.hpp to support types other than int32_t in the variadic template list Jun 18, 2021
@shuoniu-intel shuoniu-intel changed the title [SYCL] [FPGA] Update fpga_utils.hpp to support types other than int32_t in the variadic template list [SYCL] [FPGA] Update fpga_utils.hpp to support types other than int32_t in the variadic template argument list Jun 18, 2021
@shuoniu-intel shuoniu-intel changed the title [SYCL] [FPGA] Update fpga_utils.hpp to support types other than int32_t in the variadic template argument list [SYCL] [FPGA] Update handler of variadic template argument list in fpga_utils.hpp to support more types other than int32_t Jun 18, 2021
@shuoniu-intel shuoniu-intel marked this pull request as ready for review June 28, 2021 13:59
@shuoniu-intel shuoniu-intel requested a review from a team as a code owner June 28, 2021 13:59
dm-vodopyanov
dm-vodopyanov previously approved these changes Jun 28, 2021
Copy link
Contributor

@dm-vodopyanov dm-vodopyanov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@bader
Copy link
Contributor

bader commented Jun 29, 2021

to support more types other than int32_t

Is there any test checking for that?

@shuoniu-intel
Copy link
Contributor Author

shuoniu-intel commented Jun 29, 2021

to support more types other than int32_t

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.
Do you think I should add test in this patch?

@bader
Copy link
Contributor

bader commented Jun 29, 2021

Do you think I should add test in this patch?

Yes. Otherwise it's quite likely that this functionality might be unintentionally broken by future patches (e.g. code refactoring).

@shuoniu-intel
Copy link
Contributor Author

shuoniu-intel commented Jun 29, 2021

Do you think I should add test in this patch?

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.

@bader
Copy link
Contributor

bader commented Jun 29, 2021

Here are common guidelines: https://github.com/intel/llvm/blob/sycl/CONTRIBUTING.md#tests-development
@intel/llvm-reviewers-runtime should be able to provide more detailed instructions how to write a test for this feature.

@romanovvlad
Copy link
Contributor

Here are common guidelines: https://github.com/intel/llvm/blob/sycl/CONTRIBUTING.md#tests-development
@intel/llvm-reviewers-runtime should be able to provide more detailed instructions how to write a test for this feature.

It seems we need a test which verifies produced IR here. @sergey-semenov Could you please confirm?

@sergey-semenov
Copy link
Contributor

Here are common guidelines: https://github.com/intel/llvm/blob/sycl/CONTRIBUTING.md#tests-development
@intel/llvm-reviewers-runtime should be able to provide more detailed instructions how to write a test for this feature.

It seems we need a test which verifies produced IR here. @sergey-semenov Could you please confirm?

I think using static_assert to verify the correctness of the variadic templates with the newly supported types would be preferable here (would save us a run of FileCheck).

@shuoniu-intel
Copy link
Contributor Author

Here are common guidelines: https://github.com/intel/llvm/blob/sycl/CONTRIBUTING.md#tests-development
@intel/llvm-reviewers-runtime should be able to provide more detailed instructions how to write a test for this feature.

It seems we need a test which verifies produced IR here. @sergey-semenov Could you please confirm?

I think using static_assert to verify the correctness of the variadic templates with the newly supported types would be preferable here (would save us a run of FileCheck).

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.

@bader
Copy link
Contributor

bader commented Jul 6, 2021

sycl/test directory is the right place.
sycl/test/basic_tests/id_ctad.cpp - good example of using static_assert.

@shuoniu-intel
Copy link
Contributor Author

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.
However I'm not sure why Jenkins/Precommit test times out on Windows, I don't think it's related to my new commit.
(http://icl-jenkins.sc.intel.com:8080/blue/organizations/jenkins/SYCL_CI%2Fintel%2FPrecommit_Check_User/detail/Precommit_Check_User/7484/pipeline)

@bader
Copy link
Contributor

bader commented Jul 7, 2021

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.
However I'm not sure why Jenkins/Precommit test times out on Windows, I don't think it's related to my new commit.
(http://icl-jenkins.sc.intel.com:8080/blue/organizations/jenkins/SYCL_CI%2Fintel%2FPrecommit_Check_User/detail/Precommit_Check_User/7484/pipeline)

I would prefer to have the test similar to sycl/test/basic_tests/id_ctad.cpp with static_assert checks.
According to my understanding, to validate the changes made by this patch there is no need to run the compiled test, so we can reduce the test time and make it more reliable.
Does it make sense?

@shuoniu-intel
Copy link
Contributor Author

I would prefer to have the test similar to sycl/test/basic_tests/id_ctad.cpp with static_assert checks.
According to my understanding, to validate the changes made by this patch there is no need to run the compiled test, so we can reduce the test time and make it more reliable.
Does it make sense?

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.

@sergey-semenov
Copy link
Contributor

sergey-semenov commented Jul 7, 2021

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.

template <int ExpectedIntValue, enum_class ExpectedEnumValue, class... _Params> void func {
  static_assert(sycl::INTEL::_GetValue<test_int<0>, _Params...>::value == ExpectedIntValue);
  static_assert(sycl::INTEL::_GetValue<test_enum_class<enum_class::first>, _Params...>::value == ExpectedEnumValue);
}

int main() {
  func<0, enum_class::first>();
  func<1, enum_class::first, test_int<1>>();
  ...
}

Apply static_assert compile-time check.
@shuoniu-intel
Copy link
Contributor Author

Changed my test to use compile-time static_assert.

@bader bader merged commit 8636e75 into intel:sycl Jul 9, 2021
@shuoniu-intel shuoniu-intel deleted the shuoniu-br-template-list branch July 9, 2021 14:15
dm-vodopyanov added a commit to dm-vodopyanov/llvm that referenced this pull request Jul 28, 2021
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.
bader pushed a commit that referenced this pull request Jul 29, 2021
#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.
zahiraam pushed a commit to zahiraam/llvm-1 that referenced this pull request Aug 2, 2021
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.
shuoniu-intel added a commit to shuoniu-intel/llvm that referenced this pull request Aug 4, 2021
…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.
romanovvlad pushed a commit that referenced this pull request Aug 9, 2021
…ment list (#4260)

The previous patch #3957 was a
prerequisite change for the upcoming FPGA latency control feature. 
Revert due to a late change to the proposed use model API.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants