<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 27, 2014 at 3:36 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.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="">On Tue, May 20, 2014 at 2:46 PM, Tobias Grosser <span dir="ltr"><<a href="mailto:tobias@grosser.es" target="_blank">tobias@grosser.es</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 20/05/2014 22:54, Rafael Espíndola wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 15 May 2014 03:51, Tobias Grosser <<a href="mailto:tobias@grosser.es" target="_blank">tobias@grosser.es</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I would like to ask for review for the following patch:<br>
<br>
To avoid dead code elimination of the assembly printers, this patch calls<br>
InitializeAllAsmPrinters() from opt. This increases the static binary size<br>
of 'opt' from 50MB -> 52MB on my system (all backends compiled) and causes<br>
no measurable increase in the time needed to run 'make check'.<br>
<br>
Without initialising the assembly printers a shared library build of opt is<br>
linked with these libraries whereas for a static build these libraries are<br>
dead code eliminated. This is problematic for plugins<br>
that use assembly printers, as they neither can rely on opt to provide this<br>
functionality nor can they link the printers in themselves as this breaks<br>
with a shared object build of opt.<br>
<br>
As the impact is rather minor and for platforms where even a tiny binary<br>
size increase matters 'opt' is commonly not provided, I don't expect any<br>
problems. Still, I would like to ask for other opinions.<br>
</blockquote>
<br>
It seems odd to have asm printers in opt at all. I understand that is<br>
because of the current library organization, but I don't think it is<br>
an explicit design.<br>
</blockquote>
<br></div>
Right. This could probably be "fixed" but it seems the improvements in terms of code size are rather small.<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What is the plugin doing with the asm printer? Could it plugin in llc?<br>
</blockquote>
<br></div>
It is a LLVM-IR optimizer that extracts parts of the LLVM IR, translates them to PTX, stores the PTX in a global variable and generates calls to the CUDA run-time to load and run this code instead of the original code.<br>

</blockquote><div><br></div></div><div>That's pretty nuts.  If they want to use these bits, they should link their own executable that depends on all the libraries they need.  They can even compile opt/opt.cpp into their program if they like, but I think Eli Bendersky was trying to factor most of that into a library.  I'm not sure what happened with that.</div>
</blockquote></div><br>If they want to do something serious with it, sure. But as the 'opt' tool is mostly a debugging, testing, and exploration tool, what's bad about letting people try things that are pretty nuts?</div>
</div>