Fix non-strict HIP device lib order

[Snektron]

In #2045 initial support for HIP was added. While trying it out, I noticed that different runs across different machines did not yield an expected cache hit. After some investigation, it turns out that the list of bitcode device libraries is not sorted after discovering them from the file system, and this resulted in a different order across those machines. I've added a fix that simply sorts those libraries after discovering them, that seems to be similar to how its handled elsewhere.

[sylvestre]

could you please add a test for this ? thanks

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 0% with 5 lines in your changes missing coverage. Please review.

Project coverage is 62.25%. Comparing base (0cc0c62) to head (c366abf).
Report is 158 commits behind head on main.

Files with missing lines	Patch %	Lines
src/compiler/c.rs	0.00%	5 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #2217       +/-   ##
===========================================
+ Coverage   30.91%   62.25%   +31.34%     
===========================================
  Files          53       59        +6     
  Lines       20112    31049    +10937     
  Branches     9755        0     -9755     
===========================================
+ Hits         6217    19330    +13113     
- Misses       7922    11719     +3797     
+ Partials     5973        0     -5973     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Snektron]

Im not 100% sure what the best way is to add the tests, considering that fully testing that issue requires deleting and then re-adding a file from the HIP bitcode directory (/opt/rocm/amdgcn/bitcode usually). Regardless, I'm away for a few weeks and will finish this when I get back.

[Snektron]

bump

[sylvestre]

still need tests, sorry :)

[Snektron]

Seems that fuse doesn't work in github actions. I guess the only other approach swapping out calls to fs::read_dir with something that can be mocked.

[Snektron]

Hmm, it might be possible to LD_PRELOAD a library which returns random results from readdir...

[Snektron]

@sylvestre What do you think about this approach? It seems to be working fine in our fork's CI, though I feel like theres some confirmation missing that the shim is actually running. One details is that I've had to set LD_PRELOAD separately on each run, it seems that using $GITHUB_ENV will make github try to load the shim before its set up correctly in the container. I'm not really sure how that works...

[sylvestre]

please add the license header

[sylvestre]

sorry but could you please rebase it? thanks

[Snektron]

Alright, I think this is finally really ready now. I've updated the readdir randomizer with a comment that describes how and why it works the way it does, and added a simple log-based method to double check that the shim is actually running. Sorry for taking so long to finalize this...