Accessing the members of a large data structures needs a lot of GEPs which usually have large offsets due to the size of the underlying data structure. If the offsets are too large to fit into the r+i addressing mode, these GEPs cannot be sunk to their users' blocks and many extra registers are needed then to carry the values of these GEPs.
This patch tries to split a large data struct starting from %base like the following.
Before:
BB0: %base = BB1: %gep0 = gep %base, off0 %gep1 = gep %base, off1 %gep2 = gep %base, off2 BB2: %load1 = load %gep0 %load2 = load %gep1 %load3 = load %gep2
After:
BB0: %base = %new_base = gep %base, off0 BB1: %new_gep0 = %new_base %new_gep1 = gep %new_base, off1 - off0 %new_gep2 = gep %new_base, off2 - off0 BB2: %load1 = load i32, i32* %new_gep0 %load2 = load i32, i32* %new_gep1 %load3 = load i32, i32* %new_gep2
In the above example, the struct is split into two parts. The first part still starts from %base and the second part starts from %new_base. After the splitting, %new_gep1 and %new_gep2 have smaller offsets and then can be sunk to BB2 and folded into their users.
The algorithm to split data structure is simple and very similar to the work of merging SExts. First, it collects GEPs that have large offsets when iterating the blocks. Second, it splits the underlying data structures and updates the collected GEPs to use smaller offsets.
The code size and performance results of spec20xx is listed as below
Code Size (%) | Performance (%) | |
(- is smaller) | (+ is faster) | |
spec2006/bzip2 | -3.47 | +2.89 |
spec2017/imagick | -0.01 | +1.02 |
spec2000/mesa | -0.76 | +0.71 |
spec2017/x264 | -0.91 | +0.39 |
spec2017/leela | -0.01 | +0.31 |
spec2000/ammp | -0.04 | +0.17 |
spec2017/parest | 0 | 0 |
spec2017/xalancbmk | 0 | -0.13 |
spec2017/blender | 0 | -0.18 |
spec2006/xalancbmk | 0 | -0.51 |
Probably these maps should also use AssertingVH.