<div class="gmail_quote">On Tue, May 8, 2012 at 9:29 AM,  <span dir="ltr"><<a href="mailto:dag@cray.com" target="_blank">dag@cray.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">Tobias Grosser <<a href="mailto:tobias@grosser.es">tobias@grosser.es</a>> writes:<br>
<br>
> So why the intrinsic? I want to create the PTX string from an LLVM-IR<br>
> optimizer pass, that should be loaded into clang, dragonegg, opt, ..<br>
<br>
</div>You want to codegen in the optimizer?  I'm confused. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> An LLVM-IR optimizer pass does not have access to the file system and<br>
> it can not link to the LLVM back ends to directly create PTX. Creating<br>
> PTX in an optimizer pass would be an ugly hack.<br>
<br>
</div>So you _don't_ want to codegen in the optimizer.  Now I'm really<br>
confused.<br></blockquote><div><br></div><div>The device code IR would be generated in the optimization pass, and codegen'd when the host module is codegen'd.
</div><div><br></div><div>The word "codegen" is overloaded here, as we're talking about IR codegen during optimization, and device codegen during host codegen.  Confusing, no? :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
> The cleaner solution is to store an LLVM-IR string in the host module<br>
> and to mark it with the llvm.codegen() intrinsic. When the module is<br>
> processed by the backend, the string is automatically translated to<br>
> PTX. This requires no additional file writing, introduces no layering<br>
> violations and seems to be very simple.<br>
<br>
</div>Why do you need to store IR in a string?  It's already in the IR file or<br>
you can put it into another file.  All you need is an _external_ tool to<br>
drive llc to process and codegen these multiple files (to multiple<br>
targets) and then another tool to suck up the accelerator code into a<br>
string in the host assembly file.  Then you assemble into an object.<br>
<br>
No IR changes and you end up with one object file.  No changes to build<br>
systems at all, it's all handled by a driver.<br>
<br>
llvm.codegen is completely unnecessary.<br></blockquote><div><br></div><div>I believe the point Tobias is trying to make is that he wants to retain the ability to pipe modules between tools and not worry about the modules ever hitting disk, e.g.</div>
<div><br></div><div>opt -load GPUOptimizer.so -gpu-opt | llc -march=x86</div><div><br></div><div>where the module coming in to opt is just unoptimized host code, and the module coming out of opt has embedded GPU IR.</div>
<div><br></div><div>The llvm.codegen() does solve this problem, but at the cost of too much ambiguity.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
                                 -Dave<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div><br>