[patch] opt: Initialize asm printers to avoid DCE

[Reid Kleckner]

On Tue, May 20, 2014 at 2:46 PM, Tobias Grosser <tobias at grosser.es> wrote:

> On 20/05/2014 22:54, Rafael Espíndola wrote:
>
>> On 15 May 2014 03:51, Tobias Grosser <tobias at grosser.es> wrote:
>>
>>> Hi,
>>>
>>> I would like to ask for review for the following patch:
>>>
>>> To avoid dead code elimination of the assembly printers, this patch calls
>>> InitializeAllAsmPrinters() from opt. This increases the static binary
>>> size
>>> of 'opt' from 50MB -> 52MB on my system (all backends compiled) and
>>> causes
>>> no measurable increase in the time needed to run 'make check'.
>>>
>>> Without initialising the assembly printers a shared library build of opt
>>> is
>>> linked with these libraries whereas for a static build these libraries
>>> are
>>> dead code eliminated. This is problematic for plugins
>>> that use assembly printers, as they neither can rely on opt to provide
>>> this
>>> functionality nor can they link the printers in themselves as this breaks
>>> with a shared object build of opt.
>>>
>>> As the impact is rather minor and for platforms where even a tiny binary
>>> size increase matters 'opt' is commonly not provided, I don't expect any
>>> problems. Still, I would like to ask for other opinions.
>>>
>>
>> It seems odd to have asm printers in opt at all. I understand that is
>> because of the current library organization, but I don't think it is
>> an explicit design.
>>
>
> Right. This could probably be "fixed" but it seems the improvements in
> terms of code size are rather small.
>
>
>  What is the plugin doing with the asm printer? Could it plugin in llc?
>>
>
> 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.
>

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.


> Do you think it would be better to immediately restructure opt's linking
> to not link the asm printers? I looked into this briefly, but it seems to
> be a larger refactoring that adds a lot of complexity.


I'm not super familiar with the layering of lib/Target and lib/CodeGen, but
it sounds like yes, we should have some kind of minimal TTI library
per-target that exposes cost information to opt without linking in every
target.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140527/9a34f401/attachment.html>