[patch] opt: Initialize asm printers to avoid DCE

[Chandler Carruth]

On Tue, May 27, 2014 at 3:36 PM, Reid Kleckner <rnk at google.com> wrote:

> 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.
>

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140527/c40c538f/attachment.html>