[0/4] Add DF_LIVE_SUBREG data and apply to IRA and LRA

  Hi,

These patches are used to add a new data flow DF_LIVE_SUBREG,
which will track subreg liveness and then apply it to IRA and LRA
passes (enabled via -O3 or -ftrack-subreg-liveness). These patches
are for GCC 15.

These patches are separated from the subreg-coalesce patches submitted
a few months ago. I refactored the code according to comments. The next
patches will support subreg coalesce base on they. Here are some data
abot build time of SPEC INT 2017 (x86-64 target):

                          baseline   baseline(+track-subreg-liveness)
specint2017 build time :  1892s      1883s

Regarding build times, I've run it a few times, but they all seem to take
much less time. Since the difference is small, it's possible that it's just
a change in environment. But it's theoretically possible, since supporting
subreg-liveness could have reduced the number of living regs.

For memory usage, I trided PR 69609 by valgrind, peak memory size grow from
2003910656 to 2003947520, very small increase.

For SPEC INT 2017, when using upstream GCC (whitout these patches), I get a
coredump when training the peak case, so no data yet. The cause of the core
dump still needs to be investigated.

No regression on x86-64, AArch64 and RISC-V target.

Best,
Lehua

Lehua Ding (4):
  df: Add -ftrack-subreg-liveness option
  df: Add DF_LIVE_SUBREG problem
  ira: Apply DF_LIVE_SUBREG data
  lra: Apply DF_LIVE_SUBREG data

 gcc/Makefile.in          |   1 +
 gcc/common.opt           |   4 +
 gcc/df-problems.cc       | 855 ++++++++++++++++++++++++++++++++++++++-
 gcc/df.h                 | 155 +++++++
 gcc/ira-build.cc         |   7 +-
 gcc/ira-color.cc         |   8 +-
 gcc/ira-emit.cc          |  12 +-
 gcc/ira-lives.cc         |   7 +-
 gcc/ira.cc               |  19 +-
 gcc/lra-coalesce.cc      |  27 +-
 gcc/lra-constraints.cc   | 109 ++++-
 gcc/lra-int.h            |   4 +
 gcc/lra-lives.cc         | 355 ++++++++++++----
 gcc/lra-remat.cc         |   8 +-
 gcc/lra-spills.cc        |  27 +-
 gcc/lra.cc               |  10 +-
 gcc/opts.cc              |   1 +
 gcc/regs.h               |   5 +
 gcc/sbitmap.cc           |  98 +++++
 gcc/sbitmap.h            |   2 +
 gcc/subreg-live-range.cc |  53 +++
 gcc/subreg-live-range.h  | 206 ++++++++++
 gcc/timevar.def          |   1 +
 23 files changed, 1839 insertions(+), 135 deletions(-)
 create mode 100644 gcc/subreg-live-range.cc
 create mode 100644 gcc/subreg-live-range.h
  

> For SPEC INT 2017, when using upstream GCC (whitout these patches), I get a
> coredump when training the peak case, so no data yet. The cause of the core
> dump still needs to be investigated.

Typo, SPEC INT 2017 -> SPEC FP 2017
Also There is a bad news, the score of specint 2017 (with these patches) 
is dropped, a bit strange and I need to be locating the cause.
  

On 2/5/24 00:01, Lehua Ding wrote:
>> For SPEC INT 2017, when using upstream GCC (whitout these patches), I 
>> get a
>> coredump when training the peak case, so no data yet. The cause of the 
>> core
>> dump still needs to be investigated.
> 
> Typo, SPEC INT 2017 -> SPEC FP 2017
> Also There is a bad news, the score of specint 2017 (with these patches) 
> is dropped, a bit strange and I need to be locating the cause.
Just a note.  I doubt this will get much traction from a review 
standpoint until gcc-14 is basically out the door.

My recommendation is to continue development, bugfixing, cleanup, etc 
between now and then.  Consider creating a branch for the work in the 
upstream repo.

Jeff
  

This series appears to be missing documentation for the new option in 
invoke.texi.
  

On 2024/2/6 0:10, Jeff Law wrote:
> Just a note.  I doubt this will get much traction from a review 
> standpoint until gcc-14 is basically out the door.
> 
> My recommendation is to continue development, bugfixing, cleanup, etc 
> between now and then.  Consider creating a branch for the work in the 
> upstream repo.

OK, thanks for the guidance.
  

On 2024/2/6 2:17, Joseph Myers wrote:
> This series appears to be missing documentation for the new option in
> invoke.texi.
> 

OK, I'll add that. Thanks.
  

On 2/5/24 11:10, Jeff Law wrote:
>
>
> On 2/5/24 00:01, Lehua Ding wrote:
>>> For SPEC INT 2017, when using upstream GCC (whitout these patches), 
>>> I get a
>>> coredump when training the peak case, so no data yet. The cause of 
>>> the core
>>> dump still needs to be investigated.
>>
>> Typo, SPEC INT 2017 -> SPEC FP 2017
>> Also There is a bad news, the score of specint 2017 (with these 
>> patches) is dropped, a bit strange and I need to be locating the cause.
> Just a note.  I doubt this will get much traction from a review 
> standpoint until gcc-14 is basically out the door.
>
> My recommendation is to continue development, bugfixing, cleanup, etc 
> between now and then.  Consider creating a branch for the work in the 
> upstream repo.
>
>
Thank you for posting this work.  The compilation time improvement is a 
surprise for me and very encouraging.

I agree with Jeff's recommendation to create a branch as most probably 
some people (at least me :) would like to try this on own set of benchmarks.

I am planning to make a review of RA part of these patches at the 
beginning of April.  Still when I have spare time I'll look at the 
patches and could give some feedback even earlier.