On Thu, Nov 9, 2023 at 9:25 PM Vladimir Makarov <vmaka...@redhat.com> wrote: > > > On 11/7/23 22:47, Lehua Ding wrote: > > > > Lehua Ding (7): > > ira: Refactor the handling of register conflicts to make it more > > general > > ira: Add live_subreg problem and apply to ira pass > > ira: Support subreg live range track > > ira: Support subreg copy > > ira: Add all nregs >= 2 pseudos to tracke subreg list > > lra: Apply live_subreg df_problem to lra pass > > lra: Support subreg live range track and conflict detect > > > Thank you very much for addressing subreg RA. It is a big work. I > wanted to address this long time ago but have no time to do this by myself. > > I tried to evaluate your patches on x86-64 (i7-9700k) release mode GCC. > I used -O3 for SPEC2017 compilation. > > Here are the results: > > baseline baseline(+patches) > specint2017: 8.51 vs 8.58 (+0.8%) > specfp2017: 21.1 vs 21.1 (+0%) > compile time: 2426.41s vs 2580.58s (+6.4%) > > Spec2017 average code size change: -0.07% > > Improving specint by 0.8% is impressive for me. > > Unfortunately, it is achieved by decreasing compilation speed by 6.4% > (although on smaller benchmark I saw only 3% slowdown). I don't know how > but we should mitigate this speed degradation. May be we can find a hot > spot in the new code (but I think it is not a linear search pointed by > Richard Biener as the object vectors most probably contain 1-2 elements) > and this code spot can be improved, or we could use this only for > -O3/fast, or the code can be function or target dependent. > > I also find GCC consumes more memory with the patches. May be it can be > improved too (although I am not sure about this).
Note I think it's important that this can be disabled by default for -O1 which we recommend when you feed GCC with large machine-generated code which is also where I guess you'll find the effect is way worse. That includes disabling the memory usage side-effect which I guess might be hard given you grow generic data structures. > I'll start to review the patches on the next week. I don't expect that > I'll find something serious to reject the patches but again we should > work on mitigation of the compilation speed problem. We can fill a new > PR for this and resolve the problem during the release cycle. > >
