Refactor some miuses of ihipLogStatus, these should only be in top-level
HIP APIs and should be paired with HIP_API_INIT calls.
[ROCm/hip commit: 7e908bdec8]
The original implementation had the statistics system woken very
tightly into things like PPCallbacks, with counters duplicated
in two places, and all the output code duplicated. This made it
very difficult to alter the structure of the program without
breaking the statistics system.
Since the planned approach for solving the remaining preprocessor
bugs needs the introduction of a custom FrontendAction, and such
a restructure was incompatible with the way the statistics system
was set up, this rewrite was required.
'tis rather simpler now, mind you :D
This commit also fixes an issue where some stats were counted
twice, and allows `-print-stats` to operate independently of
`-stat-output`, allowing you to print stats to a file without
printing them to a terminal (or vice-versa).
[ROCm/hip commit: b303ffe53e]
operator[] default-constructs the map value if no value exists
for that key. Default-construction of int yields a zero. So all
the manual faffing around is just unnecessary.
[ROCm/hip commit: d8beee8918]
This was removed a while ago - seems like it uses a different
variant of the launch kernel function now, so this is redundant.
[ROCm/hip commit: b412802c66]
See [the documentation](https://cmake.org/cmake/help/v3.0/command/find_package.html)
for exactly how the search procedure works. If you want to use an
LLVM from a specific location, use CMAKE_PREFIX_PATH as normal.
No longer do we have a nonstandard HIPIFY_CLANG_LLVM_DIR variable
for people to learn about.
[ROCm/hip commit: 8fefc6a2b7]
Since there's now an option for toggling hipify-clang, omitting the
path is no longer something we need to check for. We'll still
abort if LLVM isn't found, due to `REQUIRED`.
[ROCm/hip commit: c60c8d417e]
Instead of deciding whether to build hipify-clang based on
the presence of an LLVM path on the command line, have an
explicit option.
Do we want this default-on or default-off? I've defaulted it to
on for now, but maybe we want the opposite?
[ROCm/hip commit: a4ecd4eb31]
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.
[ROCm/hip commit: 094b2b9b05]
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()".
[ROCm/hip commit: eff86d975b]
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.
[ROCm/hip commit: fd911e1839]
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.
[ROCm/hip commit: d1e26b2e7e]
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...
[ROCm/hip commit: 4a794ed8c0]
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.
[ROCm/hip commit: 35a892bc77]
Alex Voicu
Maneesh Gupta
Ben Sander
Wen-Heng (Jack) Chung
Evgeny Mankov
Evgeny Mankov
Chris Kitching
Siu Chi Chan
Kent Knox