<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html><body>
<span id="mailbox-conversation"></span><span class="none"><div id="mailbox-inline-edit">Thanks, all.</div>
<div id="mailbox-inline-edit"><br></div>
<div id="mailbox-inline-edit">I didn’t realize a 7.0 RC was public and changed to 3.4—I will go down that road for now, though I’ll probably also look into integrating variants of the SPIR converter in the future.</div>
<blockquote class="gmail_quote"><div dir="ltr"><div>Another possibility is to skip libnvvm altogether and use LLVM's NVPTX target. This is of course harder since you have to configure the passes yourself instead of just calling a few C functions, but it does give you more control over the optimization pipeline and gives you full visibility into the compiler. Unfortunately, there are some NVVM-specific optimizations missing upstream that we are not able to contribute back.</div></div></blockquote>
<div id="mailbox-inline-edit">I appreciate the suggestion, but this is actually for a project which has been using NVPTX for years. The problem is that we see (dramatically) better performance from our OpenCL backend (via CL C source kernels) on NVIDIA hardware simply because kernels actually get optimized through the full NVCC-style stack. Based on related experience in other projects, I expect NVVM to provide a similar or greater bump over NVPTX. In short, I’d *love* to stick with NVPTX and the open source stack in LLVM trunk, but until it provides competitive performance on real programs (which, in my experience so far, it ~never does), it’s unfortunately not a strong alternative.</div></span>
</body></html>