今天，编译器使用-d=pgoinline=1标志对PGO的行为进行了一些有限的诊断。这些实际上只是临时的日志点。出于@josharian在#55022(评论)中阐述的很好的原因，我们希望有更强大的诊断功能：
工具链及其输入越不透明，就越难(a)编写安全检查，以便在它们到达生产环境之前检测性能问题；(b)在它们到达生产环境后诊断性能问题；
以及(c)让我们更容易调查在这里提交的编译器问题。
我们当前的想法是，对于这里的初步工作，提供所有优化决策的更完整/结构化的输出，而不仅仅是“由于PGO的决定”，因为后者是模糊的。例如，如果我们决定进行内联优化，这会影响调用树中的非PGO启发式算法，那么这是否算作一个“PGO”决策？
cc @cherrymui@aclements
3条答案
按热度按时间4szc88ey1#
https://go.dev/cl/528400提到了这个问题：
cmd/compile: add pgohash for debugging/bisecting PGO optimizationsmefy6pfw2#
次要更改：
-m区分了PGO与静态去虚拟化，但没有指出启用了PGO的内联(-d=pgodebug=1是必需的)。c90pui9n3#
Bumping to 1.22. There is more structural work to be done.
For 1.21, PGO devirtualization does include structured JSON output with
-d=pgodebug=3detailing every single call with its type (direct, indirect interface, etc) and whether it was devirtualized. That can then be used for external analysis (e.g., with a tool like https://go.dev/cl/494717 ).