hfinkel added a comment. In https://reviews.llvm.org/D22666#496218, @hfinkel wrote:
> 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. Here's a patch for the backend part: https://reviews.llvm.org/D22825 - If this makes sense to everyone, we can change the frontend to add the corresponding attribute instead of inserting the function calls directly. https://reviews.llvm.org/D22666 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
