[llvm] [Draft] Support save/restore point splitting in shrink-wrap (PR #119359)

Alex Bradbury via llvm-commits llvm-commits at lists.llvm.org
Wed Dec 3 07:46:43 PST 2025


asb wrote:

Hi @enoskova-sc, with the latest push I'm not longer seeing crashes for SPEC povray, x264, and xz. I do still see one for SPEC's gcc benchmark and I'm working to reduce it (sadly this isn't quite as straightforward as the other ones).

For context, this is the diffstat after applying this patch:

```
 CFP2017rate/511.povray_r/CMakeFiles/511.povray_r.dir/home/asb/cpu2017/benchspec/CPU/511.povray_r/src/texture.s                                          |   16 +-
 CFP2017rate/511.povray_r/CMakeFiles/511.povray_r.dir/home/asb/cpu2017/benchspec/CPU/511.povray_r/src/triangle.s                                         |  226 ++++++++++++++++++++------------------
 CFP2017rate/526.blender_r/CMakeFiles/526.blender_r.dir/home/asb/cpu2017/benchspec/CPU/526.blender_r/src/blender/source/blender/blenkernel/intern/pbvh.s |  196 +++++++++++++++++----------------
 CINT2017rate/500.perlbench_r/CMakeFiles/500.perlbench_r.dir/home/asb/cpu2017/benchspec/CPU/500.perlbench_r/src/util.s                                   |    4 
 CINT2017rate/502.gcc_r/CMakeFiles/502.gcc_r.dir/home/asb/cpu2017/benchspec/CPU/502.gcc_r/src/bid2dpd_dpd2bid.s                                          |   12 +-
 CINT2017rate/502.gcc_r/CMakeFiles/502.gcc_r.dir/home/asb/cpu2017/benchspec/CPU/502.gcc_r/src/insn-automata.s                                            |  413 +++++++++++++++++++++++++++++++++-------------------------------------
 CINT2017rate/525.x264_r/CMakeFiles/525.x264_r.dir/home/asb/cpu2017/benchspec/CPU/525.x264_r/src/x264_src/common/quant.s                                 |  221 ++++++++++++++++++++-----------------
 CINT2017rate/541.leela_r/CMakeFiles/541.leela_r.dir/home/asb/cpu2017/benchspec/CPU/541.leela_r/src/FastBoard.s                                          |   36 +++---
 CINT2017rate/557.xz_r/CMakeFiles/557.xz_r.dir/home/asb/cpu2017/benchspec/CPU/557.xz_r/src/liblzma/lzma/lzma_encoder.s                                   |   80 +++++--------
 CINT2017rate/557.xz_r/CMakeFiles/557.xz_r.dir/home/asb/cpu2017/benchspec/CPU/557.xz_r/src/liblzma/simple/x86.s                                          |   47 ++++---
 CINT2017speed/600.perlbench_s/CMakeFiles/600.perlbench_s.dir/home/asb/cpu2017/benchspec/CPU/500.perlbench_r/src/util.s                                  |    4 
 CINT2017speed/602.gcc_s/CMakeFiles/602.gcc_s.dir/home/asb/cpu2017/benchspec/CPU/502.gcc_r/src/bid2dpd_dpd2bid.s                                         |   12 +-
 CINT2017speed/602.gcc_s/CMakeFiles/602.gcc_s.dir/home/asb/cpu2017/benchspec/CPU/502.gcc_r/src/insn-automata.s                                           |  413 +++++++++++++++++++++++++++++++++-------------------------------------
 CINT2017speed/625.x264_s/CMakeFiles/625.x264_s.dir/home/asb/cpu2017/benchspec/CPU/525.x264_r/src/x264_src/common/quant.s                                |  221 ++++++++++++++++++++-----------------
 CINT2017speed/641.leela_s/CMakeFiles/641.leela_s.dir/home/asb/cpu2017/benchspec/CPU/541.leela_r/src/FastBoard.s                                         |   36 +++---
 CINT2017speed/657.xz_s/CMakeFiles/657.xz_s.dir/home/asb/cpu2017/benchspec/CPU/557.xz_r/src/liblzma/lzma/lzma_encoder.s                                  |   80 +++++--------
 CINT2017speed/657.xz_s/CMakeFiles/657.xz_s.dir/home/asb/cpu2017/benchspec/CPU/557.xz_r/src/liblzma/simple/x86.s                                         |   47 ++++---
 17 files changed, 1023 insertions(+), 1041 deletions(-)
```

For the dynamic alloca problem you mention, have you looked at whether MFI.hasVarSizedObjects is sufficient?

In terms of splitting this up and landing something, being incremental and conservative for each patch is definitely what we need. But given the split shrink wrap logic kicks in so rarely with the current implementation, I'd be very interested in looking ahead a little bit to see what benefit we might get when we relax the restrictions a bit. And if that's not viable then we might need to rethink what to do.

https://github.com/llvm/llvm-project/pull/119359


More information about the llvm-commits mailing list