<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 12, 2016, at 4:11 PM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com" class="">chandlerc@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">FWIW, +1 from me as well.</div></div></blockquote>Cool.  Thanks Chandler.<br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">But I don't think you need to make this a module pass or anything else. I think you should leave the husks of the functions around and just nuke the IR out from under them. </div></div></div></blockquote>Yeah, no need for a pass unless we really want it.  I could, for example, just delete the function bodies in the AsmPrinter once we’re done with them.  Will see how that looks and get started on a patch and actual review thread.<br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">That way the module surface remains essentially identical. You can also probably nuke all the instructions from BBs with their addresses taken for jump tables, etc.</div></div></div></blockquote>Sounds good.  I never considered removing the contents of the BBs too, but thats a good idea.</div><div><br class=""></div><div>Cheers,</div><div>Pete<br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">-Chandler<br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Mar 8, 2016 at 1:16 PM Quentin Colombet <<a href="mailto:qcolombet@apple.com" class="">qcolombet@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 8, 2016, at 11:50 AM, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank" class="">echristo@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><br class=""><br class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="">I could attach a patch, but first i’d really like to know if anyone is fundamentally opposed to this.<br class="">
<br class=""></blockquote><div class=""><br class=""></div><div class="">Not necessarily. I think that any information that isn't being serialized in MI right now for a function could be as well. Definitely something for GlobalISel to keep in mind.</div></div></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap:break-word" class=""><div class=""><div class="">+1.</div><div class="">That’s basically where I would like to go with MachineModule/MachineModulePass.</div><div class=""><a href="http://lists.llvm.org/pipermail/llvm-dev/2016-January/094426.html" target="_blank" class="">http://lists.llvm.org/pipermail/llvm-dev/2016-January/094426.html</a></div><div class=""><br class=""></div>Cheers,</div><div class="">-Quentin</div></div><div style="word-wrap:break-word" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I should note, a couple of issues have come up in the prototype.<br class="">
- llvm::getDISubprogram was walking the function body to find the subprogram.  This is trivial to fix as functions now have !dbg on them.<br class=""></blockquote><div class=""><br class=""></div><div class="">This is definitely worth it, please go ahead and do this.</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- The AsmPrinter is calling canBeOmittedFromSymbolTable on GlobalValue’s which then walks all their uses.  I think this should be done earlier in codegen as an analysis whose results are available to the AsmPrinter.<br class=""></blockquote><div class=""><br class=""></div><div class="">I think this makes sense, but I worry about late added GlobalValues during code gen? How would we cope with that? Example: Let's say we start lowering a target specific construct as an MI pass etc and it constructs a global value, when do we run the analysis to make sure that all such things happen? Late as possible I'd assume. Maybe this isn't an issue, but thought I'd bring it up. At any rate, could you provide a bit more detail here?</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- BB’s whose addresses are taken, i.e. jump tables, can’t be deleted.  Those functions will just keep their IR around so no changes there.<br class="">
<br class=""></blockquote><div class=""><br class=""></div><div class="">Oh well. Conveniently there aren't a lot of these.</div><div class=""><br class=""></div><div class="">-eric</div><div class=""><br class=""></div></div></div>
</div></blockquote></div></div></blockquote></div></div></div>
</div></blockquote></div><br class=""></body></html>