Removing __ADAPTIVECPP__ ifdefs

[illuhad]

Currently, portblas uses a number of ifdefs for AdaptiveCpp and enters different code paths in a number of places:

https://github.com/search?q=repo%3Acodeplaysoftware%2FportBLAS+__ADAPTIVECPP__&type=code

From what I can see, one reason for this is group algorithms.
AdaptiveCpp 24.10 has added support for group algorithms in the generic JIT compiler (the other compilation flows already had it), so I believe there should now no longer be a reason to guard group algorithms with sufficiently recent AdaptiveCpp. But there are other ifdefs that I don't quite understand - e.g. what is the issue with the memory pool?

I'd like to find out which of these ifdefs can be removed.

• What was the motivation for these ifdefs apart from group algorithms?
• If I create a PR, would you prefer to keep compatibility with earlier AdaptiveCpp (and hence fall back to the old paths if needed), or would it be fine for you to just say that portBLAS needs at least AdaptiveCpp version 24.10?

[Rbiessy]

Thanks for the issue. Many of these ifdefs are quite old, they were most likely added because we couldn't compile the project with AdaptiveCpp otherwise. It would be great if you can help us to remove some of them!
We don't need to keep compatibility with older AdaptiveCpp versions, supporting the latest release is good enough for us.

For your information we moved the project to UXL foundation now in https://github.com/uxlfoundation/generic-sycl-components. The aim is to encourage users to use oneMath with the generic SYCL backend instead of portBLAS but the kernels are the same. We are about to archive this repository and point users to oneMath instead so we won't be accepting PRs to portBLAS. It would be great if you can contribute to https://github.com/uxlfoundation/generic-sycl-components instead and test AdaptiveCpp with oneMath!
Is this a concern for you? Were you or others users planning to use portBLAS with AdaptiveCpp?

[illuhad]

Thanks for the issue. Many of these ifdefs are quite old, they were most likely added because we couldn't compile the project with AdaptiveCpp otherwise. It would be great if you can help us to remove some of them!
We don't need to keep compatibility with older AdaptiveCpp versions, supporting the latest release is good enough for us.

Okay, I'll see what I can do :)

For your information we moved the project to UXL foundation now in https://github.com/uxlfoundation/generic-sycl-components. The aim is to encourage users to use oneMath with the generic SYCL backend instead of portBLAS but the kernels are the same. We are about to archive this repository and point users to oneMath instead so we won't be accepting PRs to portBLAS. It would be great if you can contribute to https://github.com/uxlfoundation/generic-sycl-components instead and test AdaptiveCpp with oneMath!
Is this a concern for you? Were you or others users planning to use portBLAS with AdaptiveCpp?

I see. I wasn't aware of this migration, which is why I opened the issue here. I can open a PR against uxlfoundation/generic-sycl-components, but I will say that it is currently not really attractive for me to point users towards oneMath for production use cases. My understanding is that AdaptiveCpp support in oneMath is a complex mixture of partial support and broken support, and I'm currently not planning on putting in a major effort to fix this. My interest in portBLAS was that I think that it would fold better into the deployment model of binaries generated by the AdaptiveCpp generic JIT compiler than the rest of oneMath.

[Rbiessy]

I can open a PR against uxlfoundation/generic-sycl-components

Thank you, that would be great.

To clarify the new generic-sycl-components is not meant to be used standalone, unlike portBLAS. As far as I know there are only some simple Cmake issues with AdaptiveCpp. You could enable only the generic SYCL BLAS backend if you are looking for an equivalent of portBLAS (-DENABLE_MKLCPU_BACKEND=OFF -DENABLE_MKLGPU_BACKEND=OFF -DENABLE_GENERIC_BLAS_BACKEND=ON)

[Rbiessy]

Closing as we are archiving this repository now.