LinkGPURuntime.h defines and creates a structure ForceGPURuntimeLinking which creates an artificial dependency to functions defined in GPUJIT.c. The presence of this structure ensures that these functions are a part of the compiled object/library files including it.
This line makes available the files under tools/GPURuntime.
This is for a case when a program within the LLVM tree (opt, bugpoint) would require ForceGPURuntimeLinking.h. It isn't useful when the file is to be accessed by an external entitiy, e.g. Julia, since the line(s) that'll include <polly_src>/tools will have to be added to the compile commands of the tool.
Which folder would you recommend placing this file ? It's currently in include/polly/Support.
Although the Julia (the external tool) compiled without this construct, would it be better to enclose the #include line inside this extern "C" since it specifies that the code within should be treated as C code ?
e.g. Lines like the following, in GPUJIT.c, which are allowed in the default C dialect used by GCC, would fail when compiled as C++ ( although it didn't this time. Why was that the case ? )
Should I typecast the nullptr (like in the line below) or leave it as is ?
this looks overall good. However, there is one question open:
Why are you including the full .c file? You should probably introduce a GPUJIT.h header file and only include this one. Like this there is also no need to make CUDA or OpenCL includes available when linking.
I did it this way having Julia in mind. If I had to #include just the GPUJIT.h, I'd have to link libGPURuntime.so to libjulia.so, which would require the rpath to libGPURuntime.so's location. But, the reviewers weren't happy with explicitly adding the rpath. So, I included GPUJIT.c and called every function to ensure an equivalent of linking to GPURuntime happend when I included LinkGPURuntime.h.
I'm now working to see if I could do away with GPUJIT.c and make libGPURuntime.so available by copying it to locations specified in RPATH of libjulia.so.