[PATCH] D22666: Frontend: Fix mcount inlining bug
Honggyu Kim via cfe-commits
cfe-commits at lists.llvm.org
Fri Jul 22 19:10:31 PDT 2016
honggyu.kim added a comment.
In https://reviews.llvm.org/D22666#493109, @rjmccall wrote:
> In https://reviews.llvm.org/D22666#493026, @hfinkel wrote:
>
> > What's the actual desired behavior here? Should the inliner strip out calls to mcount() as it inlines?
>
>
> I think they basically just want a late pass (as in immediately prior to codegen) to insert the mcount calls.
You're right. I wanted to move mcount insertion phase myself but it seems not that simple as I expected because mcount call is inserted in bitcode anyway, then can be optimized using `opt` tool to do function inlining later on. In this case, function inliner must strip mcount calls at the entry of each function.
Otherwise, we shouldn't generate mcount calls inside bitcode so that `opt` can simply do function inlining as it does, then code generator, `llc`, has to insert mcount just before code generation is done. I think this is not that simple as well.
To sum up, we have two approaches.
1. inliner must strip mcount calls when it does function inlining.
2. `llc` has to insert mcount calls just before code generation.
We have to choose one of these approaches. But I think this patch fixes the problem in a simpler way as of now.
https://reviews.llvm.org/D22666
More information about the cfe-commits
mailing list