这是一个开放式的性能探索想法。
我们有针对每个功能的特定编译器导出数据(参见iexport.go中的funcExt方法)。我们可以在包ssa中对返回值进行一些分析，将其添加到导出数据中，并在导入时使用它。这可能有助于无法内联的函数调用。
例如，我们可以记录一个返回值是否已知为非nil。或者一个已知的返回值范围。或者一个返回接口的函数的具体类型。
相关：#25862。如果我们追求这个想法，可以使用关于返回值的信息的机制与一些注解一起重新使用#25862。也可能用于泛化和简化ssa规则“不要对newobject的返回值进行nil检查”。
我们还可以返回诸如节点与指令的比例之类的东西，这可能有助于改进下游内联决策。
做这件事的一个奇怪之处是，从导入的包中调用函数可能会比从同一包内的函数中调用函数进一步优化。(对于#17566中提出的一些想法也存在类似的问题。)但仍然值得探索。
cc @randall77@martisch@dr2chase@cherrymui
5条答案
按热度按时间jrcvhitl1#
听起来很有趣！我们还可以记录使用的寄存器，避免未被覆盖的寄存器的溢出。
wlwcrazw2#
@TocarIP oooooooooooooooh.
7kjnsjlb3#
这对GC有轻微的影响，尽管可以安排指针总是溢出，整数可能不会。
s5a0g9ez4#
是否可以传播栈使用情况(如果已知/常量),以便调用者可以一次调用更多栈(确保有足够的空间供其自身和被调用者使用),并且被调用者可以省略更多的栈检查/调用？
yh2wf1be5#
当可以使用信号进行goroutine抢占时，这就成为可能。这是在管道中的，如果运气好的话，将在1.12中出现。这与运行时/垃圾回收如何处理栈大小调整有一些交互关系——如果F调用G调用H,F负责所有它们的帧，如果GC在G期间运行并将栈减少到适合G的程度，对H的随后调用可能会溢出栈。所以我们需要在这方面做一些工作，比如握手或标记来防止这种情况发生。