This is an archive of the discontinued LLVM Phabricator instance.

[HIP] Fix rocm not found on rocm3.5
ClosedPublic

Authored by yaxunl on Jun 11 2020, 8:55 PM.

Details

Summary

Currently rocm detector expects device library bitcodes named as *.bc
instead of *.amdgcn.bc. However in rocm3.5 the device library bitcodes
are named as *.amdgcn.bc, which causes rocm3.5 not detected.

This patch fixes that. Tested works with rocm3.5.

Diff Detail

Event Timeline

yaxunl created this revision.Jun 11 2020, 8:55 PM

Can you add tests for this? Is this also sufficient with the directory layout change?

Can you add tests for this? Is this also sufficient with the directory layout change?

You mean does this work after we move device lib from /opt/rocm/lib to /opt/rocm/amdgcn/bitcode ?

Can you add tests for this? Is this also sufficient with the directory layout change?

You mean does this work after we move device lib from /opt/rocm/lib to /opt/rocm/amdgcn/bitcode ?

Yes

tra added a comment.Jun 12 2020, 11:01 AM

Can you add tests for this? Is this also sufficient with the directory layout change?

You mean does this work after we move device lib from /opt/rocm/lib to /opt/rocm/amdgcn/bitcode ?

Yes

I can tell that it does not. We're still looking under /opt/rocm by default. I've ran into it trying to get comgr working with the recent LLVM which prompted my comment on Github

In D81713#2090265, @tra wrote:

Can you add tests for this? Is this also sufficient with the directory layout change?

You mean does this work after we move device lib from /opt/rocm/lib to /opt/rocm/amdgcn/bitcode ?

Yes

I can tell that it does not. We're still looking under /opt/rocm by default. I've ran into it trying to get comgr working with the recent LLVM which prompted my comment on Github

Not sure how that would be related to comgr? comgr doesn't rely on the dynamic path and embeds the bitcode in the library. The comgr build finds the libraries through cmake and doesn't care where they're located

tra added a comment.Jun 12 2020, 12:04 PM

I can tell that it does not. We're still looking under /opt/rocm by default. I've ran into it trying to get comgr working with the recent LLVM which prompted my comment on Github

Not sure how that would be related to comgr? comgr doesn't rely on the dynamic path and embeds the bitcode in the library. The comgr build finds the libraries through cmake and doesn't care where they're located

The version I have (~3.2. I should update it, maybe 3.5 is different) uses libclang (built from LLVM tree close to HEAD), creates Driver() instance and that driver instance goes through the motions trying to find ROCm installation and fails. Clang itself also fails the same way -- there's no /opt/rocm/amdgcn/bitcode/ it's looking for.

arsenm accepted this revision.Jun 17 2020, 1:07 PM

This only solves compatability with the old layout in the case where the hipcc wrapper is pointing directly to the library directory. I think this will still fail with the native clang search process

This revision is now accepted and ready to land.Jun 17 2020, 1:07 PM

I will commit this patch since it allows hipcc to use old rocm device library. Will fix other issues later.

This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptJun 18 2020, 5:58 AM