hfinkel added a comment. In https://reviews.llvm.org/D22666#495978, @honggyu.kim wrote:
> In https://reviews.llvm.org/D22666#493708, @rjmccall wrote: > > > Note that the presence of the mcount call itself will significantly impact > > inlining and, really, the entire optimization pipeline. Having this be a > > late pass seems more in keeping with what I assume is a goal that this > > instrumentation doesn't drastically change the generated code. > > > I agree that the best solution is to move mcount insertion phase in the late > pass so `llc` has to insert mcount calls for each function. But I don't have > clear idea how much work has to be done for this. I confess that I don't have > much experience on current LLVM code base. That's why I wrote this > workaround patch to fix the bug first, then hopefully someone can move mcount > insertion phase as you mentioned, or someone give me some guide how to do > that. Writing a new attribute `"drop_when_inlining"` seems to be a bit more > comfortable for me as Hal suggested. > Thanks for the comments. I agree with John; the right solution here is to insert the functions in the backend. As I understand it, the backend part is pretty simple. I'll write that part shortly so we can experiment. https://reviews.llvm.org/D22666 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
