[PATCH] D39480: Include GUIDs from the same module when computing GUIDs that needs to be imported.

Teresa Johnson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Oct 31 15:30:07 PDT 2017


tejohnson added a comment.

In https://reviews.llvm.org/D39480#912321, @danielcdh wrote:

> In https://reviews.llvm.org/D39480#912309, @tejohnson wrote:
>
> > Does VP metadata get synthesized from the SamplePGO profile? The original bug report had some of the targets on VP metadata attached to the indirect call, but was missing others. Why not include all the targets on that VP metadata rather than marking them for import which seems more hacky.
>
>
> Because we need to handle the indirect call chain too. E.g. foo() indirectly calls bar(), which indirectly calls baz(). Assuming these 2 calls are ICPed and inlined in the profiling binary, when processing foo's indirect callsite, marking bar's GUID in the VP is not enough, but adding baz's GUID to foo's callsite does not make sense as baz is not its call target. That's why we need to keep the transitive closure as function level metadata.


But the case here is when they are in fact in the same module. I'm assuming the situation you describe here already works when bar and baz are in different modules than foo. In this case we have foo and bar in the same module, and were missing the VP metadata showing that foo calls bar indirectly. If baz is also in the same module then the same situation applies to the callsite in bar. If it is in a different module then wouldn't the existing logic handle it? I.e. it would be on bar's function entry metadata?


https://reviews.llvm.org/D39480





More information about the llvm-commits mailing list