[SYCL] Add a test for HW threads per EU device_info query

[MrSidims]

Spec update: intel/llvm#4876
Implementation: intel/llvm#4901

Signed-off-by: Dmitry Sidorov [email protected]

[vladimirlaz]

/verify with intel/llvm#4901

[vladimirlaz]

it looks like the test is still failing with intel/llvm#4901

(see http://llvm-ci-test2.intel.com:8080/blue/organizations/jenkins/SYCL_CI%2Fintel%2FLLVM_Test_Suite_Associate_CI/detail/LLVM_Test_Suite_Associate_CI/5/pipeline)

[MrSidims]

@vladimirlaz as far as I see many, but not this test have failed. Meanwhile the associated PR's pre-commit doesn't share the same failures. In the log I see:

[2021-11-16T07:25:24.098Z] ********************

[2021-11-16T07:25:24.098Z] Failed Tests (57):

[2021-11-16T07:25:24.098Z]   SYCL :: AtomicRef/accessor.cpp

[2021-11-16T07:25:24.098Z]   SYCL :: AtomicRef/add.cpp

[2021-11-16T07:25:24.098Z]   SYCL :: AtomicRef/add_atomic64.cpp

[2021-11-16T07:25:24.098Z]   SYCL :: AtomicRef/assignment.cpp

[2021-11-16T07:25:24.098Z]   SYCL :: AtomicRef/assignment_atomic64.cpp

meanwhile intel-ext-device isn't greppable in the fail log, instead there is:
PASS: LLVM :: Basic/intel-ext-device.cpp (119 of 663)

[vladimirlaz]

@vladimirlaz as far as I see many, but not this test have failed. Meanwhile the associated PR's pre-commit doesn't share the same failures. In the log I see:

[2021-11-16T07:25:24.098Z] ********************

[2021-11-16T07:25:24.098Z] Failed Tests (57):

[2021-11-16T07:25:24.098Z]   SYCL :: AtomicRef/accessor.cpp

[2021-11-16T07:25:24.098Z]   SYCL :: AtomicRef/add.cpp

[2021-11-16T07:25:24.098Z]   SYCL :: AtomicRef/add_atomic64.cpp

[2021-11-16T07:25:24.098Z]   SYCL :: AtomicRef/assignment.cpp

[2021-11-16T07:25:24.098Z]   SYCL :: AtomicRef/assignment_atomic64.cpp

meanwhile intel-ext-device isn't greppable in the fail log, instead there is: PASS: LLVM :: Basic/intel-ext-device.cpp (119 of 663)

@MrSidims could you please analyze the failure. Potentially other tests failed due to the new test hangs/slowdowns device.

[MrSidims]

Sure

[MrSidims]

/verify with intel/llvm#4901

[MrSidims]

My bad, from the report intel-ext-device.cpp is failing, but locally for me it's passing with libsycl.so taken from my local build (with the feature).

[MrSidims]

/verify with intel/llvm#4901

[MrSidims]

@bader @vladimirlaz I believe, that something went very wrong with the pre-commit job here, please check out this PR with the exact same patch, where pre-commit went fine: #606 . Here test are failing during compilation (and re-starts didn't help). My best guess was that merge job went wrong, but I see no difference between them. Should I investigate further and what steps could you suggest?

[vladimirlaz]

@MrSidims:

• it looks like on Linux we have stable failure SYCL::Basic/intel-ext-device.cpp on Windows and Linux
• reduction_* failures on CUDA can be ignored. The regression has been fixed.
• The failures happened on Jenkins/llvm-test-suite looks similar for Windows/Linux/CUDA I do not see any clues that it is CI issue.
  You can try to restart jobs

[MrSidims]

The failures happened on Jenkins/llvm-test-suite looks similar for Windows/Linux/CUDA I do not see any clues that it is CI issue.

I've been restarting them multiple times, I had to create #606 to make it passing.

it looks like on Linux we have stable failure SYCL::Basic/intel-ext-device.cpp on Windows and Linux

How Jenkins/pre-ci-linux is different from Jenkins/llvm-test-suite ?

[MrSidims]

/verify with intel/llvm#4901

[MrSidims]

How Jenkins/pre-ci-linux is different from Jenkins/llvm-test-suite ?

@vladimirlaz
Look, I've just posted a start comment for verification - only llvm-test-suite job was restarted (not pre-ci-linux etc). In a combination with the failure during compilation of the modified test, which says, that the aspect is undefined (while it's obviously defined in intel/llvm#4901) makes me thinking, that the the pre-commit (pre-ci- jobs) are started not on top of intel/llvm#4901 .

[vladimirlaz]

@tfzhu, @DoyleLi could you answer Dmitry's questions?

[DoyleLi]

Hi @MrSidims. Here are answers for your questions:

How Jenkins/pre-ci-linux is different from Jenkins/llvm-test-suite ?

Yes, that is what we designed for the pre-ci of intel/llvm-test-suite.
Jenkins/pre-ci-linux is running on nightly build of intel/llvm project.
While Jenkins/llvm-test-suite is triggered by comment on demand that to run the test with head commit of associate PR from intel/llvm (defined in comment).
So generally speaking the two ci jobs should have different result. And that can give the engineer an apparent comparision with and without the patch on peer side.
For the current PR#550, we can find "Jenkins/pre-ci-linux" executed test based on intel/llvm@2fa6376 from intel/llvm sycl branch (The sycl branch head commit when do nighlty build that day).
And Jenkins/llvm-test-suite is running with "intel/llvm PR-4901|Commit-7eb3053d4a0bcfe40f75a843fce4ebe4215fbc85" from intel/llvm.

....makes me thinking, that the the pre-commit (pre-ci- jobs) are started not on top of intel/llvm#4901 .

Yes, as the comment above, Jenkins/pre-ci-linux will only be triggered by new commit operaiton in the PR instead of comment "/verify with XXX", and will use nightly build of intel/llvm instead of head commit of peer side to run the ci test. If not, there will have no difference between "Jenkins/pre-ci-linux" and "Jenkins/llvm-test-suite".

......please check out this PR with the exact same patch, where pre-commit went fine: #606

I think the reason #606 went fine is, the new PR 606 was committed today so it was executed with new nightly build based on intel/llvm@7c3a9f1

For more details about the CI process, please email to me and I will paste you some wiki as reference.

[MrSidims]

Yes, as the comment above, Jenkins/pre-ci-linux will only be triggered by new commit operaiton in the PR instead of comment "/verify with XXX"

@vladimirlaz @bader in this case, if SYCL::Basic/intel-ext-device.cpp is not failing in llvm-test-suite job (at least I don't see it, sorry if I miss it), can we merge both intel/llvm and test PR?

[vladimirlaz]

closed in favour of #606