[patch] opt: Initialize asm printers to avoid DCE

[Tobias Grosser]

On 28/05/2014 00:56, Chandler Carruth wrote:
> 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?

Hi Reid,

I agree our use case is rather experimental and I am very happy to hear 
comments on this e.g. on the Polly mailing list.

I understand that for a production tool that just wants to reuse opt's 
functionality Eli's approach of making opt's functionality available as 
a library is probably best. Our use case is purely to test 
functionality. This is similar to what Chandler pointed out:

"there are *many* use cases for an 'opt' plugin to want to use the rest 
of LLVM libraries. Things such as dumping asm for specific 
function/target pairs for debugging, maybe a world of other things I've 
not thought about. Making plugins to opt have access to more parts of 
LLVM seems strictly better the more I think about it -- this has 
essentially no cost to the LLVM-side layering, and lets folks experiment 
with more and different things"

As opt already links to these libraries, I am currently only trying to 
address an inconsistency that dead-code-eliminates these libraries in
certain situations. In the context of the comments above, do you think 
this would be OK?

Cheers,
Tobias