Use of grep in `lit` RUN lines is deprecated:
https://llvm.org/docs/TestingGuide.html#writing-new-regression-tests
Using grep leads to really unhelpful failure output (it literally
just says "the test failed"). FileCheck is much more helpful, and
distributed with LLVM on most distros anyway, so this extra
dependency shouldn't prove problematic.
This just... isn't a target. Maybe you were trying to do a file
dependency? But that's handled implicitly by the find_program
call anyway, so all this is doing is generating a cmake warning
This bug was present all along, but something changed in the order
of de-initialisation performed by llvm that makes it actually
crash now.
The constructor of HipifyPPCallbacks gives:
```
std::unique_ptr<HipifyPPCallbacks>(this)
```
to the LLVM Preprocessor instance. The Preprocessor instance
subsequently frees the HipifyPPCallbacks, which is then freed
again when we leave the stack frame at line 4340.
So: let's leak the HipifyPPCallbacks onto the heap, and leave
the LLVM Preprocessor object responsible for tidying it up.
The Preprocessor smart pointer is held by the CompilerInstance,
and therefore its reference count cannot reach zero until the
CompilerInstance itself is destroyed.
If the CompilerInstance is destroyed, you have more to worry about
than just the preprocessor being deallocated!
Newer versions of the LLVM/Clang API migrated to using
std::shared_ptr, so there is no `Retain()` function (by that
name, anyway). Eliminating this redundant use is a neat and
backward-compatible way to become compatible with newer versions
of the LLVM/Clang API.
Newer versions of llvm/clang mean there is both an
llvm::StringLiteral and a clang::StringLiteral. Since we're
dumping both namespaces wholesale into the global namespace with
`using` declarations, this creates a name collision, which must be
resolved.
This change is backwards-compatible, and fixes a problem you
encounter when using newer versions of the llvm/clang API.
What we actually want to do here is use the StringRef version in
versions newer than 3.8, and the void one in 3.8 and older.
Checking "major-version >= 3 && minor-version >= 9" does not do
what we want. Consider what this will do for version 4.0, for
which minor-version is zero...
PythonInterp is a finder module that ships with cmake. It supports
the conventional interaction with find_package that allows you
to demand success, and particular vesions, without having your
own logic:
https://cmake.org/cmake/help/v3.0/command/find_package.html
This copies to the output after operation, instead of working
_on_ the output. This allows includes to work correctly, while
supporting output paths anywhere on the filesystem.
Fixes#208Fixes#206
[Synopsis]
If any of kernel arguments is a MACRO its location calculation is wrong (location of its definition is actually calculated).
Thus garbage code is being produced on the place of such a MACRO starting from the end of its actual definition.
[Solution]
Add isMacroBodyExpansion and isMacroArgExpansion checks on kernel arguments.
[hipify-clang] Finally finished syncing with CUDA 8.0.61 Driver and Runtime API (including missing data types, D3D, OpenGL, VDPAU and EGL interop).
+ All the Modules are supported now:
1) 4.1 – 4.31 from CUDA 8.0.61 Driver API
2) CUDA_Driver_API_functions_supported_by_HIP.md updated accordingly
3) 4.1 – 4.31 from CUDA 8.0.61 Runtime API
4) CUDA_Runtime_API_functions_supported_by_HIP.md updated accordingly
+ Typos fixing
+ Annotating
+ CUDA_Driver_API_functions_supported_by_HIP.md update.
+ Initial update of HIPIFY with CUDA driver API functions:
1.Error Handling, 2.Initialization, 3.Version Management, 5-6.Device Management, 7.Primary Context, 8-9.Context, 10.Module Management, 11.Memory Management.
+ Sync HIP functions against CUDA Driver and Runtime API functions.
+ Typo fixes.
ToDo: 12-30 modules of CUDA Driver API.
+ Memory advise values
+ Memory Range Attributes
+ P2P Attributes
P.S.
There is no any new changes in CUDA Driver API 8.0.61 Data structures since 8.0.44.
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/issues/80
Example from CUDA 8.0.44 sample (CUDASamples\0_Simple\matrixMulDrv\matrixMulDrv.cpp):
CUjit_option *jitOptions = new CUjit_option[jitNumOptions];
where CUjit_option is enum, should be:
hipJitOption *jitOptions = new hipJitOption[jitNumOptions];
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/issues/81
1. Do not use JIT options on HCC path, call hipModuleLoadData instead.
2. NVCC path is unchanged, to call cuModuleLoadDataEx with all options.
3. Get rid of manual hipification, based on #ifdef #else for NVCC/HIP.
4. Update documentation accordingly.
Chris Kitching
Evgeny Mankov
Evgeny Mankov
Maneesh Gupta