寄存器压力太大时，lra spill过多，导致性能不好

源码：spec 519 lbm.c 函数：LBM_performStreamCollideTRT line 336附近的代码，BB 5

spill for spill

bB
BB 5

在local ra之前，寄存器基本已经耗尽。那么当前的lra，在处理local reg时，对于每一个点，都需要去spill 一个已经分配好的寄存器来拿到一个可用寄存器。导致代码中很多 spill for spill 的操作。

可以尝试的解决方案：

提前做bb的压力评估，针对类似场景，关闭local ra.
对local reg也计算conflict的。让冲突信息更准确些，而不是像当前一样，在分配之前，对于所有关联的global reg用过的寄存器都不能使用。这个我们在arm32上有做过优化。
对于global reg的spill处理时，可以做优化。java里因为有异常，所以要在每个点都单独spill for spill。C语言，可以在BB的开始统一spill，函数结束时统一reload。

这是一个很普遍的问题，造成了至少三个spec用例性能的明显下降，基本上只要出现大块的计算无跳转，就会出现这个问题：
538　magick/morphology.c　　MorphologyPrimitive　3021~3037行左右
544　nab eff.c ephi

特殊场景：
对大结构体拷贝，我们现在是生成很多条str/load, 每次都给一个新的vreg. 导致，函数会产生很多的vreg，它们的live range很短，属于local ra。如果按global ra去计算conflict的话，时间开销很大。比如，我们的一个supertest用例，拷贝结构体：

# define LENGTH (32763)

struct s { short a[LENGTH]; } s1;
struct t { struct s ss; char cc[4]; } s2;
s2.ss = s1;

输入图片说明

vreg过多，会让conflict计算时间膨胀。

fullcolor已经包含了调整lra的改动。我们会尽快使能

GVP 方舟编译器 / OpenArkCompiler

内容风险标识

评论 (3)

GVP方舟编译器 / OpenArkCompiler

内容风险标识