[patch] opt: Initialize asm printers to avoid DCE

[Tobias Grosser]

On 28/05/2014 07:29, Chandler Carruth wrote:
> On Tue, May 20, 2014 at 2:57 PM, Rafael Espíndola <
> rafael.espindola at gmail.com> wrote:
>
>>> 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.
>>>
>>> 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 am honestly not sure. There were some discussions about what should
>> be in opt or in llc in the future. I remember proposals ranging from
>> opt not linking to CodeGen to just merging the two. I don't have a
>> strong opinion on the direction, but it would be nice to know that
>> this patch is pointing the right way.
>>
>> Chandler, do you know what the current consensus is?
>
>
> There are an increasing number of IR-level passes that can query into
> target-specific information. Testing these from 'llc' is kind of horrible,
> and so the plan of record AFAIK is to freely allow the 'opt' tool to link
> bits of the target libraries.
 >
> While I'm of two minds about the specific use case, I think 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.

Right, I believe dumping asm e.g. to do some kind of code-size or 
register allocation auto-tuning might also be interesting. However, many 
of such use case may be more interesting for experiments or debugging 
that for actual production work.

Was this some kind of 'LGTM' or would you like to have further 
discussions on this topic?

Also, in case you have comments/suggestions regarding our specific use 
case, please feel free to raise them (possibly in a different thread).
Yabin's project is more a proof of concept, but getting feedback early 
on the ideas and directions he is taking seems strictly positive, 
especially if you would like to point out possible problems.


Cheers,
Tobias