On 08/21/2013 09:36 PM, Peter Colberg wrote: > The hack is the missing communication of parameter sizes from the > kernel invocation in the backend to the LLVM pass. That would need > some ugly string formatting and parsing for the sizes of local and > constant memory arguments.
I'm not sure I got this. Is this related to the fact that you do (in LocalParams) the reverse what the old GenerateHeaders (now split to AutomaticLocals by Kalle) did and it loses the size of the arguments and you need it to invoke the libcuda? Which patch has this? > You mentioned that a future goal is to migrate from compiler scripts > to direct LLVM API calls. I thought about trying that instead, to Yes, this work has been progressed by Kalle recently. He already did convert the GenerateHeader (pocl-kernel) so LLVM API can be used instead. It can be enabled with ./configure --enable-llvmapi > communicate parameters, but then the backend needs to be compiled > with the C++ compiler. Do you intend to keep the backends in C? No, I don't see any point in that. E.g. the ttasim driver is already C++ because TCE has a C++ API. > The LLVM C API is certainly far from usable for a transformation > such as that of local/constant parameters to module-scope arrays. > I doubt that it would be time well spent to maintain a C wrapper > for all required LLVM C++ functions and data structures. It is > probably better to directly use the LLVM C++ API. You are probably right. Too bad LLVM C++ API is unstable which means #ifdefs, but I'm used to it already ;) > Maybe you could devise style guidelines that allow C++ in the backends > (or everywhere?), but, e.g., disallow the use of the STL? While very > practical, the STL hides complex functionality behind innocent-looking > one-line constructs, which may not be a good idea for a library with > high performance and low overhead in mind. The main motivation for C is not really the speed, but platform portability. There probably will be use cases (at least in our research projects) where one wants to compile (parts of) the host side API implementations on quite bare bone devices with only C compilation support. Therefore, I'd prefer to keep as much of it compilable using a plain C compiler as possible. Avoiding hidden complex functionality is a big bonus in this scenario. However, the reasoning to allow C++ in some parts is that, e.g., the ttasim device driver requires libtce which means you already need to have everything that TCE needs to enable it. Similarly we can argue that for online compilation of kernels we need a better equipped environment with LLVM and Clang running. And clang supports C++, so in my opinion it's OK to allow C++ for interfacing to LLVM. Similar rationale goes for your cuda driver that requires libcuda which requires Linux or similar. -- --Pekka ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ pocl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pocl-devel
