Tested with CUDA 8.0, 9.0, 9.1 and 9.2.
Only 8.0 works with LLVM 7.0, due to the changes in LLVM trunc since released 6.0, which works fine with CUDA 8.0 and 9.0.
So, nothing to do in hipify-clang, hope that all the CUDA 9.x related issues will be fixed in 7.0 release.
[ROCm/hip commit: 433e172776]
+ supported CUDA version to LLVM version correspondence table is added.
+ Test section is rewritten.
+ Windows support is added.
[ROCm/hip commit: 054c3f71f0]
/srv/HIP/hipify-clang/src/main.cpp:134:19: error: no member named 'dbgs' in namespace 'llvm'
DEBUG(llvm::dbgs() << "Skipped some replacements.\n");
~~~~~~^
[ROCm/hip commit: 7f3e89bbb0]
Due to support of cuRAND headers.
+ compound test on all headers is added;
+ missing entities are added with updating the doc;
+ a couple cuRAND tests are added (https://github.com/ROCmSoftwarePlatform/rocRAND/tree/master/benchmark):
- the following CUDA entities are still unsupported by hipRAND:
curandMakeMTGP32Constants
curandMakeMTGP32KernelState
curandGetDirectionVectors32
curandDirectionVectorSet_t
CURAND_DIRECTION_VECTORS_32_JOEKUO6
curandStateSobol64_t
curandStateScrambledSobol64_t
curandGenerateLongLong
- and the following - by HIP:
cudaRuntimeGetVersion
- those entities are handled by CHECK-NOT directive for now.
[ROCm/hip commit: 02e23c4d87]
File location have to be verified, otherwise location of the first found '#pragma once' in any included header even system will be erroneously handled, which might lead to attempt to including hip_runtime.h in it.
[ROCm/hip commit: 77f807b597]
If in source CUDA file main header (cuda_runtime.h or cuda.h) is not presented, corresponding HIP main header (hip_runtime.h) should be explicitly included in output hipified file.
[Algorithm]
1. If #pragma once is presented, HIP main header should be placed just after it;
2. Otherwise if any other (not CUDA main) header is presented, HIP main header should be placed just before it;
3. Otherwise HIP main header should be placed in the beginning of output file.
P.S.
There might be one more situation when #ifndef #define ... #endif guard for the entire file is presented (make sense for *.h, *.hpp, *.cuh files). In this case HIP main include should be placed just after such #ifdef, or after #pragma once, if it is also presented. This situation will be handled in a separate change.
[ROCm/hip commit: 09655a0853]
// hipified to #include<hip/hip_runtime.h>
#include<cuda.h> // 1st cuda main include (Driver API)
// to eliminate
#include<cuda_runtime.h> // 2nd cuda main include (Runtime API)
HIP has one header hip_runtime.h for both CUDA APIs, thus second cuda main include directive is eliminated entirely.
[ROCm/hip commit: 7e7cfa10cc]
Function require_program erroneously doesn't report "Can't find program" on any missing program except the first one due to the cached FOUND_PROGRAM value.
Additionally:
+ Do not throw FATAL_ERROR on missing program in order to obtain the whole list of missing programs (if any).
+ Report also found program location.
[ROCm/hip commit: 56bffb5999]
As HIP has started to support vanilla CUDA syntax for threadIdx, blockIdx, blockDim and gridDim.
Other CUDA builtins are not tracked for now.
[ROCm/hip commit: 71d2fb20c8]
Much pretty. Very wow
This gives users all the usual power when it comes to manipulating
clang diagnostics. People can pass -Werror can have hipify fail if
it doesn't completely translate a file, for example. Much nicer
than reinventing the wheel.
[ROCm/hip commit: 6b767a59ba]
Most of what hipify does is really just replacing CUDA idenitifers
with HIP ones. CUDA function calls, preprocessor macro calls,
enum references, types, etc.
This is problematic: calls/types/enum-refs require name resolution
for the AST matcher to work. This fails in the presence of code
deleted by the preprocessor, and in two-pass template compilation.
Instead, we can simply hook the lexer and have it rewrite the
identifiers for us.
This approach means identifier transformations will work correctly
regardless of where they appear (and we get to delete lots of code)
- Fixes#260
- Helps a bit with #207 - it will still fail to translate kernel
calls in preprocessor-ignored code, but everything except kerel
launches should translate correctly now, even in
preprocessor-deleted code.
[ROCm/hip commit: 24cdc5e1d3]
Evgeny Mankov
Maneesh Gupta
Evgeny Mankov
Chris Kitching