Rename hipSYCL to AdaptiveCpp, update CI and regenerate filter

[psalz]

NOTE: This includes @fknorr's recent PRs (#870, #871, #872, #873), so those should be merged first.

This renames (hopefully) all uses of hipSYCL to AdaptiveCpp and updates the version checked against in CI to the latest develop commit (the previous version was over 2 years old at this point).

I've also gone ahead and re-generated the CI exclude filters: AdaptiveCpp is now able to compile 7 additional categories (device, exception_handling, image, marray, nd_range, range and vector_alias), while failing 2 new categories (group_functions and optional_kernel_features, although I believe those didn't even exist yet the last the filter was generated).

I had to bump our CI docker container base image to Ubuntu 22.04, as the GCC included in 20.04 is too old for current AdaptiveCpp.

I've also taken the liberty of removing the long deprecated Intel_SYCL option for SYCL_IMPLEMENTATION.

cc @illuhad

Closes #796.

[bader]

NOTE: This includes @fknorr's recent PRs (#870, #871, #872, #873), so those should be merged first.

I'm not sure it's a good idea. These PRs have some unresolved comments and pre-commit failures, which will take time to resolve. Requesting them to be merge first blocks other useful work, which is not directly related to adding SimSYCL support.

I think we can merge fix for #796 and remove the Intel_SYCL separately.

[psalz]

I'm not sure it's a good idea. These PRs have some unresolved comments and pre-commit failures, which will take time to resolve. Requesting them to be merge first blocks other useful work, which is not directly related to adding SimSYCL support.

I think we can merge fix for #796 and remove the Intel_SYCL separately.

Are we in a hurry to get this merged? IMO waiting another week or two to get those issues resolved doesn't really make a difference at this point. My main goal for today's call was to assess AdaptiveCpp's current CTS coverage, and not including @fknorr's fixes will negatively affect that.

[keryell]

How do we move on this?

[keryell]

@fknorr Some merge conflicts.
We could use also Ubuntu 24.04 to have some recent compilers out of the box?

[bader]

I've also taken the liberty of removing the long deprecated Intel_SYCL option for SYCL_IMPLEMENTATION.

This part has been removed from the PR.

[psalz]

Well this has taken way too long, sorry about that. I've re-done all of the text replacements and updated the AdaptiveCpp image to a recent commit. It looks like there's fewer test categories compiling now than when I originally opened the PR, but I haven't checked any of the errors, so there might be some low hanging fruit.

[illuhad]

For #1012, we should decide for whether we want an LLVM-based build. In this context, I wonder whether there is any issue or challenge enabling the compiler features?

Since AdaptiveCpp even when only targeting CPU now typically relies on LLVM (via --acpp-targets=generic by either JIT-compiling for OpenMP or OpenCL), we could use such a build without having to set up CUDA or ROCm and without needing GPU hardware.

As most users also are going to be using --acpp-targets=generic, that might be useful to have in CTS CI, if possible.

[bader]

@illuhad, I managed to install LLVM and successfully built default version of AdaptiveCpp. Unfortunately, I can't merge #1012 because SYCL-CTS code base relies on hipSYCL. I think this PR resolve the issue blocking #1012.
Could you please approve this PR and review #1012?

[psalz]

I suggest to merge this PR first and then look into switching to SSCP in a follow up. It should only require changes to the Dockerfile (hopefully), and by merging this now we can get all the string replacements out of the way before they accrue too many conflicts with other PRs.

[bader]

Sounds good to me. @illuhad?

[illuhad]

Yep, okay for me!