Fix Kokkos_Sort when using integer and HIP

[Rombur]

This is a fix required by vtkm. There is something weird happening with integer arithmetic and HIP. I don't understand why but some integer operations that should be fine (i.e. there is no overflow) are wrong. Casting to int64_t fixes the problem.

[dalg24]

Retest this please

[crtrott]

5: [ RUN      ] sycl.mdrange_large_deep_copy
5: 
5: PI CUDA ERROR:
5: 	Value:           1
5: 	Name:            CUDA_ERROR_INVALID_VALUE
5: 	Description:     invalid argument
5: 	Function:        cuda_piEnqueueKernelLaunch
5: 	Source Location: /scratch/llvm/sycl/plugins/cuda/pi_cuda.cpp:2661
5: 
5: unknown file: Failure
5: C++ exception with description "Native API failed. Native API returns: -30 (CL_INVALID_VALUE) -30 (CL_INVALID_VALUE)" thrown in the test body.
5: [  FAILED  ] sycl.mdrange_large_deep_copy (370 ms)

any idea?

[masterleinad]

5: [ RUN      ] sycl.mdrange_large_deep_copy
5: 
5: PI CUDA ERROR:
5: 	Value:           1
5: 	Name:            CUDA_ERROR_INVALID_VALUE
5: 	Description:     invalid argument
5: 	Function:        cuda_piEnqueueKernelLaunch
5: 	Source Location: /scratch/llvm/sycl/plugins/cuda/pi_cuda.cpp:2661
5: 
5: unknown file: Failure
5: C++ exception with description "Native API failed. Native API returns: -30 (CL_INVALID_VALUE) -30 (CL_INVALID_VALUE)" thrown in the test body.
5: [  FAILED  ] sycl.mdrange_large_deep_copy (370 ms)

any idea?

That's the error we tried to fix for CUDA in particular. I would not expect that this pull request changes anything. Did this actually work correctly for SYCL in the pull request that added this test?

[Rombur]

I've rebased on develop. Let's see if that helps

[Rombur]

Rebasing didn't help :/

[masterleinad]

Rebasing didn't help :/

I think we just need to adapt the test for SYCL in some way...

[fnrizzi]

@Rombur
When you say "some integer operations that should be fine (i.e. there is no overflow) are wrong" does this mean that even something "simple" like the following gives wrong result but what does wrong mean?
Is there something particular that pops up from looking at the result? or it seems totally random?

mul_(std::is_integral<typename KeyViewType::const_value_type>::value
                 ? 1.0 * max_bins__ / (int64_t(max) - int64_t(min))
                 : 1.0 * max_bins__ / (max - min)),

Does it give wrong result all the time or only for certain values of the parameters?
if the operation above is an example of a such failure maybe it would make sense to add a test for integer operations for HIP?

[Rombur]

Hmm it looks like the problem is integer overflow. Not sure why I thought it wasn't.

[crtrott]

@Rombur can you address francescos comment?

[Rombur]

I already did

[fnrizzi]

I guess we postpone adding a test tailored to check this?