Unify more CUDA and HIP files into common

[upsj]

A lot of the files we have in common/cuda_hip don't work standalone, but instead require to be included with certain other includes being available. Here I'm trying to change this, allowing the files to be parsed from tooling more easily, and making it easier to write CUDA and HIP code simultaneously.

I did many of these modifications automatically using the unify_cuda_hip.py python script, or using plain text replacement to fix the headers

Some related questions:

• What should be the canonical place of including hip_runtime.h? I don't think we should have to do that with every file, instead something like config.hip.hpp or types.hip.hpp seems most appropriate
• Should hip::config be used on host or device or both? If we use it on the device only, we should be able to handle ROCm gfx10 and gfx11 not supported #1429 more easily, the host side should instead be handled with a runtime value, like exec->get_warp_size()

[sonarqubecloud]

Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
No data about Coverage
17.8% Duplication on New Code

See analysis details on SonarCloud

[MarcelKoch]

TBH, I'm not sure if this can be reviewed by humans. 200+ changed files are not easily processed manually. So I guess we have to rely on our CI. If you could provide some key files to look at, that would help a lot.
But in general terms, unifying redundant code sounds good to me. Is the goal to unify as many files as possible and only exclude those, where the actual implementation differs? If so, maybe a list of files that are not suitable would be helpful.

[upsj]

@MarcelKoch Most of these changes are 90% automatical, but the remaining 10% is what's interesting. I'll see what I can do in terms of providing a diff what changed beyond the automated stuff. I reviewed a similar PR in the past using meld's three-way comparison.

[MarcelKoch]

Perhaps the easiest is if you already know where the 10% interesting stuff is, you could just give us a list of files and then we can manage.

[upsj]

I had to do so many small changes, I can't really remember, I'll have to reproduce that in an automated fashion

[MarcelKoch]

TBH, I'm not sure if the places where you did manual changes are that important. AFAIK the changes are mostly code movement, with the addition of perhaps some wrappers around the moved code. And I'm somewhat confident that our CI would catch errors on that level. If there are any changes besides that, it would be good to know if you can point us to those.
Otherwise, the question of review is rather on the concept itself and not on the individual changes.

[upsj]

Some of the changes handle inconsistencies between CUDA and HIP versions, some of which might have performance implications, so I don't want to just rely on CI here.

[upsj]

@MarcelKoch I agree, that would be my next goal

[yhmtsai]

two left in my mind: preconditioner/jacobi_common.hpp and header guard

[yhmtsai]

when it becomes the header, it needs the header guard

[upsj]

The file is not self-sufficient without the unified/kernel_launch.hpp header, just like before, so it does not need one.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
18.0% Duplication on New Code

See analysis details on SonarCloud