[Sparse BLAS] remove deprecation warning when using oneMKL 2024.1 with sparse::trsv() on x86 CPU and Intel GPU backends

[spencerpatty]

Description

oneMKL 2024.1 deprecated sparse::trsv() without an alpha scaling factor and introduced a new sparse::trsv() with alpha. We update trsv backend calls to use the new one from oneMKL 2024.1 with constant fixed alpha == 1 to avoid the deprecation warnings.

Checklist

All Submissions

• Do all unit tests pass locally? Attach a log.
• Have you formatted the code using clang-format?

Bug fixes

• Have you added relevant regression tests? (N/A)
• Have you included information on how to reproduce the issue (either in a
  GitHub issue or in this PR)? (N/A)

[Rbiessy]

Thanks for the PR. I am wondering for how long do we need to support previous MKL releases?
Previous releases are not tested AFAIK so I am not sure it is worth complexifying the code with macros.

[spencerpatty]

Thanks for the PR. I am wondering for how long do we need to support previous MKL releases? Previous releases are not tested AFAIK so I am not sure it is worth complexifying the code with macros.

To me, it makes sense to support the latest MKL minor release, but also the latest MKL Major release as well, but seeing as we always use the latest compiler, maybe it also just makes sense to support the latest MKL release and not distinguish between minor and major releases ? I also agree that having macros to complexify the code is not so good, luckily here it is a simple change, but it could be much worse ... If we agree to not worry about minor/major, I can quickly just drop the else part of this fix.

[Rbiessy]

I would avoid the macro in this case. They don't seem to be used in the project so far.

[mmeterel]

Thanks for the PR. I am wondering for how long do we need to support previous MKL releases? Previous releases are not tested AFAIK so I am not sure it is worth complexifying the code with macros.

To me, it makes sense to support the latest MKL minor release, but also the latest MKL Major release as well, but seeing as we always use the latest compiler, maybe it also just makes sense to support the latest MKL release and not distinguish between minor and major releases ? I also agree that having macros to complexify the code is not so good, luckily here it is a simple change, but it could be much worse ... If we agree to not worry about minor/major, I can quickly just drop the else part of this fix.

Typically, we claim support for only latest oneMKL product - which is in the latest base tool kit (not distinguished between minor/major releases).