<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 20, 2014 at 2:57 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.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="">> Right. This could probably be "fixed" but it seems the improvements in terms<br>
> of code size are rather small.<br>
><br>
><br>
>> What is the plugin doing with the asm printer? Could it plugin in llc?<br>
><br>
><br>
> It is a LLVM-IR optimizer that extracts parts of the LLVM IR, translates<br>
> them to PTX, stores the PTX in a global variable and generates calls to the<br>
> CUDA run-time to load and run this code instead of the original code.<br>
><br>
> Do you think it would be better to immediately restructure opt's linking to<br>
> not link the asm printers? I looked into this briefly, but it seems to be a<br>
> larger refactoring that adds a lot of complexity.<br>
<br>
</div>I am honestly not sure. There were some discussions about what should<br>
be in opt or in llc in the future. I remember proposals ranging from<br>
opt not linking to CodeGen to just merging the two. I don't have a<br>
strong opinion on the direction, but it would be nice to know that<br>
this patch is pointing the right way.<br>
<br>
Chandler, do you know what the current consensus is?</blockquote></div><br>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.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">-Chandler</div></div>