All but the most contrived use of macros is now properly handled -
have a look at the new testcases this commit adds. You can have
macros in kernel calls, macros spanning chunks of your arguments,
the call, call parameters, or callee can all be macros or
partially macros.
It seems like there was a lot of machinery here that is no longer
needed now we have hipLaunchKernelGGL (which doesn't require us
to insert an extra argument into kernel functions). We no longer
need to waste cycles scanning the AST for callees.
We can literally just do "Take the callee expression, and dump
it into the first argument of hipLaunchKernelGGL()".
There's three functions here that all do the same thing...
There was also logic that looks for numeric literals and works
backwards to find the macro name from which they are expanded.
I previously introduced code that rewrites macro references at
expand-time in the `MacroExpands` callback, so that code is no
longer doing anything useful.
Calls to macros that were themselves CUDA API calls were often
being missed - this applies the identifier transform to macro
names at the callsites, too.
The source location for a call that's inside a macro body will,
by default, point into the macro definition itself. The original
logic was causing macro invocations to be overwritten, as I
explain here:
https://github.com/ROCm-Developer-Tools/HIP/issues/207#issuecomment-337521851
The existing PPCallbacks code is correctly rewriting macro
definitions, so the practical effect of this change is that AST
rewrites on code that's expanded from macros are no-ops.
It might be a performance optimisation to put a short-circiut at
the top of the AST callbacks to abort when faced with code that
was expanded from macros.
It might yet prove wise to do absolutely everything at lex-time...
A chain of 7 closing braces is never a great sign :D
In the process it became apparant that the unsupported flag
was being silently ignored, causing users to be left with cuda
API calls in their programs with no warning given. This has been
rectified for consistency.
Instead of having a single, enormous LUT for all CUDA names, let's
have separate ones for different types of entity. We often know
that we're looking at a typename, or a function name, or a macro
name - so we can be more efficient (and resilient to name
collisions) by having smaller lookup tables for each of those
classes of entity).
Here we start that off by having three LUTs:
- Header names
- Type names
- Everything else
Future work could usefully split "everything else" into:
- enum values
- macro names
- function names
- everything else
It's worth noting that the "needs new matcher" todos I delete here
were actually resolved with the previous commit. It no longer
naively searches for things that start with "cu*" - it will find
exactly those things that are present in our lookup tables.
Previously, there were different AST matchers for each
language construct that contains a type reference, and custom
logic to perform the transformation within each of those
structures.
Since the transformation in all such cases was only replacing
CUDA types with hip ones, we can instead use an AST matcher
that finds and updates the type references directly.
This simplifies the program considerably, and it won't fail
when it finds a language feature (or complicated type expression)
that nobody wrote custom logic for yet.
Also, rewrote it as a constant variable instead of a function
that imperatively fills a map. It's shorter, faster the compile,
and (depending on how badly the compiler screws it up) maybe
faster to run.
And, of course, it starts breaking up that giant .cpp file.
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...
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