Yaxun (Sam) Liu

I can help with option 1: patch clang [1] to look in /usr/share/hip/.hipVersion (or perhaps /usr/share/hip/version). Also I am considering emitting HIP version predefined macro from clang instead of hipcc....

> Great, thanks a lot for your reply @yxsamliu! > > > I can help with option 1: > > patch clang [1] to look in /usr/share/hip/.hipVersion (or perhaps /usr/share/hip/version)....

> Yes, agreed, the check in clang should account for install locations in `/usr/share/hip/` and `/usr/local/share/hip/`. > > However, if I understand the [current logic](https://github.com/llvm/llvm-project/blob/llvmorg-14.0.6/clang/lib/Driver/ToolChains/AMDGPU.cpp#L451-L459) for finding `.hipVersion` correctly, then...

> > I think your understanding is right. clang first tries to deduce the HIP intallation path relative to its own path. If clang is in /usr/bin, it tries to...

They should work in a diverging control flow.

The threads in a wavefront could be partially inactive and these functions will still work. For 'any', a comparison is done for all active lanes and the results are collected...

I would expect the result to be '0101...01' but currently hip-clang gets '1111...111'. This because LLVM pass SimplifyCFG merged the two calls of __any, which makes the kernel equivalent to:...

I am using ROCm5.1 and gfx906. The issue also exists with llvm trunk.

It seems the issue is with SimplifyCFG no matter whether __any is inlined or not. If __any is not inlined, the IR before and after SimplifyCFG is: `*** IR Dump...

posted an RFC to llvm for fixing this issue https://discourse.llvm.org/t/rfc-introduce-cross-lane-function-attribute-to-prevent-merging-call-of-cross-lane-functions/62148