[PATCH] D96978: [WIP] Bias statepoint operands towards spilling

Serguei Katkov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 30 03:26:57 PDT 2021


skatkov added a comment.

Hi Philip, I've landed the test CodeGen/X86/statepoint-ra-no-ls.ll which shows the immediate impact of this patch.
It shows that with this patch RA prefer to evict the VR with use in statepoint var use and as a result we eliminate redundant spill.

However the test is very limited. The reason of this is a split. So the test is written to avoid any splits.
Note that spill weight depends on the weight of spill/fill operation but also on size of live interval which is used in
normalization. This effect is very important on small intevals.

If you add additional statepoint instruction into the test Local Split will be triggered and it breaks everything. The same problem will be with region split, but let's start first with local split.
First of all Local Split (RAGreedy::tryLocalSplit) also estimates the spill weight of the future split live interval and does not take into account statepoint var operands (see computation of EstWeight).
As a result its computed value will be bigger then VirtRegAuxInfo::weightCalcHelper produces. It should be fixed actually to be consistent.
However it is not enough. Split operation introduce additional use in COPY at end of interval. As a result spill weight will be at least 2 before normalization.
On small intervals where number of def/uses it is big enough and size of live interval starts playing significant role.
I though about prohibit splitting on statepoint instruction but not sure it is really profitable in all cases. For example if we evict another VR, probably it might be split in a way that all intervals will be on physical registers and no need in spilling at all. 
In other words I want to prefer spill of VR with use in statepoint but only if we really need to spill anyone.
Does it make sense? Any thought?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D96978/new/

https://reviews.llvm.org/D96978



More information about the llvm-commits mailing list